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
weemooseus@[EMAIL PROTECTED]
where would StarLogo fit in this?
Not?
Carl
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
it now.
Carl
__._,_.___
LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum
> 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
> gene_sullivan@[EMAIL PROTECTED]
>
>
> --- In LogoForum@[EMAIL PROTECTED]
"clemrutter" <clemrutter@[EMAIL PROTECTED]
> wrote:
> >
> > I am still being asked the question: Is this a LOGO, or is
> > this not a LOGO?
>
> > This is usually followed by the question If this is not a LOGO,
> > what do I need to do to make it LOGO?
>
> > So can we as a group get
> > together to make up a definitive definition, and put together may be 5
> > one line tests that can be used to illustrate this?
> >
> > 1a. Basic syntax
> >
> > A test maybe: make "n 100 if 110 = sum first bf [ 7 10 23] :n [pr
> > [VALID]]
> >
> >
> > 1b. Basic graphics
> > A test may be: etc
> >
> > 2. Base system- both 1a and 1b validate
> >
> > 3. Base system with trig functions
> >
> > 4. UCB compliant
> >
> > 5. UCB compliant with extensions as listed.
> >
> > These are purely illustrative to start the conversation. But I
> > envisage we developers could aim for the tests.
> > We could then describe a logo as say 'Level 2 but missing
> > the fill facility '.
> >
> > There are lots of issues- but could we have a go!
>
> This seems like `Deja vu all over again'.
>
> http://groups.yahoo.com/group/LogoForum/message/12744
> http://groups.yahoo.com/group/LogoForum/message/12129
> for examples.
>
> Though this time I have some other approaches I haven't
> put forth yet.
>
> It has occurred to me that improvements might be made by
> framing `the issue' in a couple of different ways.
>
> Brian's mentioning of how some logo imps use `edit', an
> IDE feature. This got me to thinking that some hassles
> might be avoided if a logo scripting standard were developed
> in which interactive editing weren't allowed. One could
> launch a logo script in batch mode which evoked `standard'
> features .... for `logo script', `batch logo', or whatever it
> would be called. This framework might simplify the
> user interface hassles somewhat ... to allow a process to
> start and gather momentum.
> {note: a logo `filter' might be developed ... but perhaps with
> stdGrphx in addition to stdin, stdout, and stderr}
>
> Another framework which came to mind is to focus on a
> framework for pulling up each unique implementation by the
> bootstraps incrementally. In this framework, features like
> quasiquoting and hygienic macros (employed by Logo's cousin, Scheme)
> could be used to extend a common bare bones `root stock' of
> infrastructural primitives by `grafting' on the specialized features
> which give each implementation it's unique look and feel.
>
> Brian also mentioned another issue involving scoping: lexical VS
> dynamic. As lexical scoping can be used to implement dynamic scoping,
> but -- unless I am mistaken -- not the other way around,
> it might be good to have lexical scoping used in the `root stock'
> infrastructure and have extensions (modules, libraries, whatever)
> flesh out the details of implementing dynamic binding/scoping and such.
>
> Perhaps I didn't thoroughly read all the posts in this thread, but
> I don't recall anybody raising the possibility of back-propagating
> a few system variables and procedures into extant logo designs which
> render them all a share more self-aware. To wit, features which allow
> a running program to discover which logo version it is compliant with,
> or which feature set it has.
> Pavel has already implemented something like this in Elica and Lhogo.
> If other logo camps adopted this then programmers could use `if'
> statements as wrappers around implementation-specific code ... and
> `standard' libraries (like clib for c, and slib for scheme) could
emerge.
>
> Just a few thoughts,
> Gene
> >
>
> __._,_.___
> LogoForum messages are archived at:
> http://groups.yahoo.com/group/LogoForum
|
