Andreas Micheler <Andreas.Micheler@[EMAIL PROTECTED]
> writes:
>Communication/FileAccess/minimal [close closeall eraseFile renameFile
>setReaderPos setWriterPos ReaderPos WriterPos EOFP FileP]
>Arithmetic/TrigonometricFunctions/minimal [Sin Cos Tan ArcSin ArcCos
ArcTan]
>Graphics/TurtleMotionQueries/minimal [Pos Heading Pixel]
These are a few "minimal" feature sets to which UCBLogo would have to say
False (no renameFile, ArcSin, Pixel), even though it does have /most/ of
the
primitives in each category.
>Loops/minimal [forever repeat repcount while for]
No Logo had repcount before UCBLogo, I believe, and the commercial ones
mostly still don't. Meanwhile, Microworlds has alternatives DoTimes and
DoList that aren't in here.
My point is that categories like these are too coarse. And we already
have
PROCEDUREP, which allows users to test for exactly the features they
really
want. (Mostly. PROCEDUREP won't tell you, for example, whether arctan
will
take two inputs.)
Anyway, these are the sort of differences that can be resolved with
libraries.
It's the syntax, and related problems (non-text save files in some Logos,
for
example, making programs non-****table), that are the real killers.
You could, were it not for syntax-related problems, write these
feature-set
tests as Logo procedures, using procedurep. But instead of true and
false,
I'd write them to return the subset of the feature set that the
implementation
does sup****t.
(I mean, I'm flattered that most of your feature lists, and their
organization, come from UCBLogo, but I'm not convinced that's fair to
implementations, especially the commercial ones, whose design predates
UCBLogo.)
|
