Andreas Micheler <Andreas.Micheler@[EMAIL PROTECTED]
> writes:
>So, why is there no renameFile function in UCBLogo?
Things that have to be done differently on each platform have always been
low on my list. But if we ever get the wxWidgets version working (we keep
running into wxWidgets bugs, different ones on each platform, ugh) I think
they have a file manipulation API so maybe we'll include 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.
That's the least of the reasons for Pixel. (Btw, the traditional Logo
name
for this is ColorUnder for the color under the turtle, or ColorAt for the
color at a given position.) It's useful for all kinds of things, like
inventing your own floodfill. :-) It's not in UCBLogo because some of the
underlying graphics APIs don't sup****t it. I think wxWidgets does,
though,
so we'll add that.
>OK, I didn't know that.
>Just take it out into "optional".
[It doesn't matter what the "that" is for my purposes. :-) ] This misses
my
main point, which is that if people want to know about compatibility, they
want to know about the particular primitives they use, not about groups of
primitives. So instead of this whole structure I think the best thing to
provide would be
to doesLogoSup****t :primlist
output emptyp find [not procedurep ?] :primlist
end
(Of course this works only in dialects that sup****t FIND, but that can be
written in Logo in any dialect I know of.)
>> 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.
You say you agree, but I don't see a proposal for
doesLogoRequire "spaces.around.operators
or
areLogoWorkspacesPlainTextFiles
and so on. My point was that those are way more im****tant than whether
this Logo implementation includes some primitive.
|
