Brian Harvey wrote:
> 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.
I know. I just wanted to have some starting point for the discussion.
So, why is there no renameFile function in UCBLogo?
It is pretty often very useful, instead of having to write
shell (list "ren :source :dest)
And I'm not sure if "shell" should be in the minimal set.
But of course we can put "renameFile" in the optional group.
"ArcSin" is a similar case.
I just thought it might be worth including it.
The case of "Pixel" is indeed different:
I strongly argument to implementing it,
because else no test suite for the graphical functions could be written,
which should be working without user interaction.
>> 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.
OK, I didn't know that.
Just take it out into "optional".
> 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.)
That's true, but there's "Arity" (at least in a few Logos). ;-)
> 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.
I certainly agree.
But, even if "doesLogoSup****t" may be written in Logo itself
in some dialects, I believe it could be useful.
The coarseness can be improved, by introducing more categories like
"minimal","optional","3d", ect. Maybe "optional2" ...?
I'm just searching the greatest common divisor,
and I don't know other Logos so well, so I will have to learn a lot. :-)
> 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.
Good idea, maybe as another, additional operation, maybe
"SubsetLogoSup****ts"
But a simple "true or "false is sometimes also good to know,
because it is easy to use.
You don't need to know the "count" of the full compliance with booleans,
which is what will be mostly needed to analyze "SubsetLogoSup****ts".
> (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.)
Oh, I don't wanted to be unfair.
I just browsed the aUCBLogo help, and looked for im****tant features. ;-)
Some I forgot, many I don't know of, which are in other Logos.
What I wanted to aim is some movement in the direction of a standard,
so that all developers have something to chew on,
and I was also a bit provoking. ;-)
But my list looks like some very useful set of functions.
If a Logo does not comply to some sub-set folders,
it would not be that bad for people,
who just have other interests than that sub-set.
If one wants to write a ****table program,
that draws something special, then no one cares about files. ;-)
Cheers,
Andreas
|
