Re: Syntax simplification

In <dgvhrc$sop$1@xxxxxxxxxxxxxxxxxxxxxxx> bh@xxxxxxxxxxxxxxxxxxxxxxx (Brian Harvey) writes:
>>Maybe I should write commands like START and END to keep people in
>>the domain of lists until I'm ready to tell them about types?
[...]
>>IMO, the type/behaviour polymorphism of {BUT,}{FIRST,LAST} has always
>>been somewhat fishy.
>I think that the whole idea in Logo is to *have* different types (words and
>sentences) without much *thinking about* types at all. If you hang out with

Um... but a long section of your book "computer science Logo style" are
dedicated to explaining the difference of words and one-word sentences,
and that of empty words and empty sentences.
(http://www.cs.berkeley.edu/~bh/v1ch2/proced.html)

>computer scientists, or C/Java programmers, then the first thing you want to
>know about something is its type. But if you forget all about computers, and
>think about natural language, everyone knows that words and sentences are
>two different things, but everyone naturally talks about them with overlapping

I'm not so sure about this. First off, I know several people who really
do have difficulty seeing the difference between the word "Hey and the
sentence [Hey!] (other than the presence or lack of an exclamation
point).

Second, people generally do not understand what it means to "take the
first of the word 'foo'" or to "take the first of the sentence 'foo
bar'". Instead, they understand what it means to "take the first
character of the word 'foo'", "take the first character of the sentence
'foo bar'", or "take the first word of the sentence 'foo bar'". Some
have a mild uneasiness about "take the first word of the word 'foo'",
but come into the "right" conclusion ("foo") anyway. They express
almost similar uneasiness to "take the first word of the sentence 'foo'"
(where the sentence has one word only).

Third, sentence already exhibits polymorphic behaviour that does seem
sensible to me: it promotes words into single-word sentences while
appending its args.

So, based on these observations, I'm tempted to make the following:

- unify words and single-word sentences, as well as empty words and
empty sentences (use [] uniformly for quoting, because it's more
generic).

- define different operations for taking the first _character_ of a
datum, and taking the first _part_ of a datum, with the following
semantics:
first [foo bar] -> [foo] first-char [foo bar] -> [f]
first [foo] -> [foo] first-char [foo] -> [f]
first [f] -> [f] first-char [f] -> [f]

- define bf to return the part that first does not return. Similarly
for bf-char. Define last, last-char, bl and bl-char symmetrically.

(But note that bf-char and bl-char are problematic with subsentences:
what is bf-char [[hello there] [see you later]]? Is it
[|hello there]| [see you later]] (hopefully not), [[ello there] [see
you later]] or something else? And what about bf-char [[] foo] or
bf-char [z foo]?)

- define wordp and listp (or sentencep) as
to wordp :datum to sentencep :datum
op equalp :datum first :datum op not wordp :datum
end end

>vocabularies. ("Overlapping" because you don't talk about the subject of a
>word or the suffix of a sentence. But I claim that if you take someone off
>the street and ask "how long is this word?" or "how long is this sentence?"
>while pointing to an appropriate example, you'll get an answer in letters in
>the first case or in words in the second case.)

You're probably right about the use of the word "length" or the phrase
"how long"... although, while nobody will report the length of a word in
words, I _could_ easily imagine somebody reporting the length of a
sentence in something other than words.

>Oh, I see. Yes, it's an old (but inconsistent) Logo tradition to use
>nullary functions for named constants, such as colors.

During this discussion I've become unsure about the exact relation
between variables and constants (in natural languages, of course, not
programming languages). Both are kinds of nullary functions; variables
evaluate to something they refer to, while constants evaluate to
themselves. But what does it mean to "evaluate to itself"? Is the word
3 really the same as the value 3? As a long tradition suggests, there
is no problem with this notion. For what kinds of words is it safe to
make them represent themselves?

And to make the mess worse, it makes sense for some composite
expressions to evaluate to themselves, too. For example, suppose we
have color-of and my, which are unary functions. Suppose further that I
don't know the color of my hat. Now, it makes sense for [color-of my
hat] to evaluate to [color-of my hat].

>As for variables, the reason for defaulting to global is the same as the
>reason for dynamic scope -- the user should not have to know that there is
>such a thing as scope of variables!

This is an interesting point. I would never have thought that people
have problems understanding the concept of scope -- or that somebody
would have _more_ trouble understanding lexical scope, which is
linguistically oriented, than dynamic scope, which is
execution-oriented.

Panu

--
personal contact: atehwa@xxxxxx, +35841 5323835, +3589 85619369
work contact: panu.kalliokoski@xxxxxxxxxxx, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
.

Relevant Pages

  • Re: Trouble with variable scoping
    ... You are confusing file scope with global. ... That is possibly the most common misperception about Perl that I've ... fully-qualify any global variables you decide to use. ... a lexical variable $foo exists in the current scope. ...
    (perl.beginners)
  • Re: Syntax simplification
    ... >dedicated to explaining the difference of words and one-word sentences, ... >and that of empty words and empty sentences. ... If you don't know the color of your hat, ... >have problems understanding the concept of scope -- or that somebody ...
    (comp.lang.logo)
  • Re: Signal handlers, objects and reference counting.
    ... "local", then it would automatically destroy the sub-ref, which would then ... lexical scope and the SIG localization goes out of dynamic scope. ... package foo; ... Does each circularity lie entirely within one module, ...
    (comp.lang.perl.misc)
  • Re: weird bug
    ... package Foo; ... immediately surrounding scope. ... Either you parse the eval string ...
    (comp.lang.perl.misc)
  • Re: case/when question
    ... irb:003:0> def foo range ... Variables r1 and r2 are NOT in scope inside foo which is exactly what ruby told me. ...
    (comp.lang.ruby)