The message below is being cross-posted from the LogoForum. Please
reply here at comp.lang.logo and it will be cross-posted back to the
LogoForum. The original author of this message is
pavel@[EMAIL PROTECTED]
Micheler wrote:
> The coarseness can be improved, by introducing more categories like
> "minimal","optional","3d", ect. Maybe "optional2" ...?
This could make the number of categories bigger that the number of
primitives :O
> 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. :-)
That's why making the Atlas would be easier if many people contribute
(preferably at least one for each included dialect)
Pavel
__._,_.___
LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum
In article <60s0fuF1sfcm9U1@[EMAIL PROTECTED]
>,
Andreas Micheler <Andreas.Micheler@[EMAIL PROTECTED]
> wrote:
> 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
|
