Frank Heckenbach wrote:
Scott Moore wrote:
And a simple rule: if the parameter does not exist, leave it out !
Good example indeed. But it is a case where default parameters may be even better suited -- if there are n such parameters, with overloads you'll need 2^n routines.
In theory, yes. For practical matters, the number never rises above 8 (three optional parameters).
I don't think so.
They largely import type checking from compile time to runtime.
Not really. An additional runtime type-check would be necessary when e.g. a formal parameter is of a discriminated schema type and the actual parameter is of an undiscriminated type (i.e., a parameter itself or a pointer). However, this case is extremely rare -- the exact opposite is the common case, where all type-checking can be done at compile time.
If used for array bounds (as is indeed common), some range-checking becomes a little more expensive (comparing two variables rather than a variable and a constant), and some range checks (though rarer) have to move from compile time to run time. True, this is a runtime price, but it's far smaller than you make it appear. Furthermore, with any other concept for dynamic arrays, you get the same price, AFAICS.
Dynamic arrays are pretty much what the whole issue is about. First, Oberon dispenses with the lower bound check, which I think is proper. Second, whenever you introduce a mix of dynamic and fixed arrays there are problems. If you specify a parameter as dynamic, convertions happen when called with a fixed, etc. In fact, there is considerable incentive to add bounds variables to ALL arrays, fixed or not, just to keep compatibility. So I stay with what I said, the overhead is greater with schemas, for no added benifit.
Schemas fundamentally (and permanently) degrade Pascals runtime performance.
What do you mean permanently? It only affects code that uses schemata, other code is not affected.
As programmers get used to using schemas, it is permanent. Using the method in IP Pascal, there is no incentive to use dynamic when a fixed array would do, so there is no incentive to use more expensive schema types.
And again, what are your alternatives? When I use schemata for dynamic arrays, you have another implementation of dynamic arrays which surely also requires more runtime range checks.
Typically in a schema you must carry a pointer to a template (a runtime data structure describing the schema type to be accessed). With simple dynamics, as IP and Oberon implemented, there is only the array length, and it can be picked up or not depending on if the array type is being accessed dynamically or not.
When I use schemata for other purposes, you need explicit code which in the end probably does almost the same at runtime which schema code does implicitly.
Further, type safety is an attribute independent of implementation.
Finally, I debate that schemas are necessary for Pascal. The prime problem schemas are used for is to create dynamic length arrays. Indeed, that was the entire reason schemas were considered for creation in the first place. Instead, IP Pascal uses a completely type safe method
I don't know why you keep insisting on type-safety when the alternatives (default parameters, address operators, schemata) are just as type safe. I wonder if you have understood the schema concept at all if you actually think they're type-unsafe.
I didn't say that, and now we are insulting. So we are going to agree to disagree.
Anyway, I have some uses of schemata which are more then dynamic length arrays, but since you obviously don't care, I won't bother explaining.
Frank
I'm sorry you felt you needed to put this on a personal level. I am actually confused why you felt that was required, but I have had examples of it before. I think we are done. Kinda sad, really, we cannot have a reasonable conversation.