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
|
