[LogoForum] Re: Logo: Tests for compliance.

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@yahoo.nospam.com.


--- In LogoForum@yahoogroups.com, "clemrutter" <clemrutter@...> 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

gene_sullivan@yahoo.nospam.com says:
>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.

This misses the point of the example. I happened to pick EDIT to mention
but could just as easily have picked ERASE or even (longer ago) MAKE. The
issue isn't about interactivity but about whether special forms are used to
make the most common case easier to type, or whether syntactic uniformity
is valued.

>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.

Well, first of all, you /are/ mistaken -- see, for example, my Pascal
compiler in CSLS vol 3. But secondly, if we are to make this sort of
argument, then the conclusion has to be that we should forget about Logo
altogether and just program in God's programming language, Scheme.
The /whole point/ of Logo is user interface. It's all Lisp inside,
but what makes Logo Logo is a collection of choices about what kids will
find natural/easy/inviting.

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
taobert@yahoo.nospam.fr



Brian Harvey says:
> The /whole point/ of Logo is user interface.* It's all Lisp inside,
> but what makes Logo Logo is a collection of choices about what kids will
> find natural/easy/inviting.

Logo as a natural, easy, user friendly Lisp... I agree

Just a question, to mischievously boost the discussion:
Can we standardize Logo without it losing its soul?

(and what's the soul of Logo )

Bertrand


__._,_.___
LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum








In article <fonm41$23ge$1@agate.berkeley.edu>,
bh@cs.berkeley.edu (Brian Harvey) wrote:

> gene_sullivan@yahoo.nospam.com says:
> >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.
>
> This misses the point of the example. I happened to pick EDIT to mention
> but could just as easily have picked ERASE or even (longer ago) MAKE. The
> issue isn't about interactivity but about whether special forms are used to
> make the most common case easier to type, or whether syntactic uniformity
> is valued.
>
> >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.
>
> Well, first of all, you /are/ mistaken -- see, for example, my Pascal
> compiler in CSLS vol 3. But secondly, if we are to make this sort of
> argument, then the conclusion has to be that we should forget about Logo
> altogether and just program in God's programming language, Scheme.
> The /whole point/ of Logo is user interface. It's all Lisp inside,
> but what makes Logo Logo is a collection of choices about what kids will
> find natural/easy/inviting.

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
tomcsanyi@slovanet.nospam.sk.



At 11:25 11.2.2008, Bertrand Carette wrote:
>Just a question, to mischievously boost the discussion :
>Can we standardize logo without it losing its soul?

Good point.

And my answer is "NO".

Logo is 40 (years old).
Can you imagine what happens if you try to force rules to a 40 years
old human who has lived all his previous life without keeping to strict
rules?

Peter

__._,_.___
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
> taobert@yahoo.nospam.fr
>
>
>
> Brian Harvey says:
> > The /whole point/ of Logo is user interface.* It's all Lisp inside,
> > but what makes Logo Logo is a collection of choices about what kids will
> > find natural/easy/inviting.
>
> Logo as a natural, easy, user friendly Lisp... I agree
>
> Just a question, to mischievously boost the discussion:
> Can we standardize Logo without it losing its soul?
>
> (and what's the soul of Logo )
>
> Bertrand
>
>
> __._,_.___
> 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
pavel@elica.nospam.net.


Peter Tomcsanyi wrote:
>> Can we standardize logo without it losing its soul?
>
> And my answer is "NO".

I hate to repeat myself, but I think it might be helpful to remind you
that there are two types of standard. I do not know the official
terminology, but the more widespread type is the *restrictive* standard.
It enforces a fixed description and everything outside it is considered
wrong. Actually when thinking about standards most people think about
exactly this type of standard.

The other standard is *non-restrictive* one -- it
describes/enumerates/classifies already existing entities, and does not
enforce that new entities should comply with the already existing ones.

My opinion is that restricted standard is either impossible or
harmful/lethal for Logo. However, the *non-restrictive* standard would
put some order by sorting things out. So whenever I say I want a Logo
standard, I mean the *non-restrictive* standard.

Think of Logo as of a natural language. We all know (of think that we
know) what English language is. But there is no way to frame it in a
restrictive standard, because it evolves and changes... AS WE USE IT.

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
> tomcsanyi@slovanet.nospam.sk.
>
>
>
> At 11:25 11.2.2008, Bertrand Carette wrote:
> >Just a question, to mischievously boost the discussion :
> >Can we standardize logo without it losing its soul?
>
> Good point.
>
> And my answer is "NO".
>
> Logo is 40 (years old).
> Can you imagine what happens if you try to force rules to a 40 years
> old human who has lived all his previous life without keeping to strict
> rules?
>
> Peter
>
> __._,_.___
> 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
> > taobert@yahoo.nospam.fr
> >
> >
> >
> > Brian Harvey says:
> > > The /whole point/ of Logo is user interface.* It's all Lisp inside,
> > > but what makes Logo Logo is a collection of choices about what kids will
> > > find natural/easy/inviting.
> >
> > Logo as a natural, easy, user friendly Lisp... I agree
> >
> > Just a question, to mischievously boost the discussion:
> > Can we standardize Logo without it losing its soul?
> >
> > (and what's the soul of Logo )
> >
> > Bertrand
> >
> >
> > __._,_.___
> > 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
pavel@elica.nospam.net.


Brian Harvey wrote:

> but what makes Logo Logo is a collection of choices about what kids will
> find natural/easy/inviting.

Really? So it's a waste of time to make a Logo compiler...

Pavel

__._,_.___
LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum




In article <fonm41$23ge$1@agate.berkeley.edu>,
bh@cs.berkeley.edu (Brian Harvey) wrote:

> gene_sullivan@yahoo.nospam.com says:
> >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.
>
> This misses the point of the example. I happened to pick EDIT to mention
> but could just as easily have picked ERASE or even (longer ago) MAKE. The
> issue isn't about interactivity but about whether special forms are used to
> make the most common case easier to type, or whether syntactic uniformity
> is valued.
>
> >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.
>
> Well, first of all, you /are/ mistaken -- see, for example, my Pascal
> compiler in CSLS vol 3. But secondly, if we are to make this sort of
> argument, then the conclusion has to be that we should forget about Logo
> altogether and just program in God's programming language, Scheme.
> The /whole point/ of Logo is user interface. It's all Lisp inside,
> but what makes Logo Logo is a collection of choices about what kids will
> find natural/easy/inviting.

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@yahoo.nospam.com


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@yahoo.nospam.com.
>
>
> --- In LogoForum@yahoogroups.com, "clemrutter" <clemrutter@...> 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

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@elica.nospam.net.



Carl 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@yahoo.nospam.com
>
>
> 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@yahoo.nospam.com.
> >
> >
> > --- In LogoForum@yahoogroups.com, "clemrutter" <clemrutter@...> 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

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
taobert@yahoo.nospam.fr.




--- In LogoForum Pavel Boytchev* wrote:

Think of Logo as of a natural language. We all know (of think that we
know) what English language is. But there is no way to frame it in a
restrictive standard, because it evolves and changes... AS WE USE IT.
---------------------------

I was getting at that point precisely. Logo as a (nearly) natural
language. Rebol tried to do it,* inspired by Logo (as I see it).*

Every natural (let's say human) language must respect a standard in
order to be usefull and efficient as a communication tool.* But a
*restrictive* standard could get this language become ancient;* in
french we say this language is a "dead language" (une langue morte).

So I like this idea of a *non-restrictive* standard which respects the
foundations of the language while allowing some freedom of expression.
This allows "programing as poetry" and above all the creation of the
tools which make "poetry" possible.

What about a Logo Academy , as the "French Academy" whose main function
is to keep an eye on the development of the language* ... and maybe, at
the end of it all, a Logo Dictionnary with definitions and synonyms ?
----------------------------------

--- In Logo, Pavel Boytchev wrote:

Really? So it's a waste of time to make a Logo compiler...

*in reply to Brian Harvey:

but what makes Logo Logo is a collection of choices about what kids
willfind natural/easy/inviting.
----------------------------------

I think Logo lost a lot of time while it was regarded as a programing
language for kids, and even a childish language, because most of the
users fell on the friendly turtle and didn't go further.

Now Logo has the right to make up for lost time . So I don't think it's
a waste of time to make a Logo compiler. On the contrary this is in line
with what has been said above about the evolution of Logo,* by means of
a *non-restrictive* standardization.

Regards,
Bertrand





__._,_.___
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
> pavel@elica.nospam.net.
>
>
> Peter Tomcsanyi wrote:
> >> Can we standardize logo without it losing its soul?
> >
> > And my answer is "NO".
>
> I hate to repeat myself, but I think it might be helpful to remind you
> that there are two types of standard. I do not know the official
> terminology, but the more widespread type is the *restrictive* standard.
> It enforces a fixed description and everything outside it is considered
> wrong. Actually when thinking about standards most people think about
> exactly this type of standard.
>
> The other standard is *non-restrictive* one -- it
> describes/enumerates/classifies already existing entities, and does not
> enforce that new entities should comply with the already existing ones.
>
> My opinion is that restricted standard is either impossible or
> harmful/lethal for Logo. However, the *non-restrictive* standard would
> put some order by sorting things out. So whenever I say I want a Logo
> standard, I mean the *non-restrictive* standard.
>
> Think of Logo as of a natural language. We all know (of think that we
> know) what English language is. But there is no way to frame it in a
> restrictive standard, because it evolves and changes... AS WE USE IT.
>
> Pavel
>
> __._,_.___
> LogoForum messages are archived at:
> http://groups.yahoo.com/group/LogoForum
>
>

pavel@elica.nospam.net says:
>> but what makes Logo Logo is a collection of choices about what kids will
>> find natural/easy/inviting.
>
>Really? So it's a waste of time to make a Logo compiler...

Interestingly, they're having this very argument over on comp.lang.scheme
as we speak.

Everyone's different, as we've all been saying. For myself, I would find
very useful a "just in time" compiler that feels, to the user, exactly like
an interpreter except that the programs run a lot faster. I would find
less useful a "batch" compiler that requires everything to be in a source
file including the top-level instruction that sets it going.