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]
Bogardus wrote:
> Hmm, where would StarLogo fit in this?
>
> Not?
Fitting applies there are boundaries or limitations.
For example, if you consider that C is yellow, and all C-implementations
and dialects are various shades of yellow, then it is relatively easy to
define whether something fits in the definition.
Now imagine Pascal is red. Imagine some other language is blue.
The problem is that Logo, being a rainbow, does not fit in any of the
color boxes, but still it can be described and enjoyed!
What if we 'fix' Logo to be from red to blue and some day an infrared
Logo comes to us? Or an ultraviolet? No problem. We just add them to the
spectrum of features...
Pavel
__._,_.___
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
> weemooseus@[EMAIL PROTECTED]
>
>
> Hmm, 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
|
