[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 14 22:50:29 2001 
Subject:Re: filenames, argument list separators + gsl extension 
From:Chris Dollin 
Volume-ID:1010514.10 

In article <9dpkp0$95a$1@ctb-nnrp2.saix.net>,
	cglur@onwe.co.za writes:
>> Space being a valid char in an identifier, seems absurd.
> 
> kers@hplb.hpl.hp.com  wrote:
> 
>> Why?
>> 
>> Spaces occur in identifiers all over the place. Here are some examples.
>> 
>>     Christopher James Dollin
>>     Windows 95
>>     Red Hat Linux
>>     The Sorceress and the Cygnet
>>     Thief of Time
>>     A Song for all Seasons
>>     Shifting Sands
>>     For Girls Who Grow Plump In The Night
>>     Spice manual
>>     Chatty guide
>>     Hewlett-Packard Laboratories
>>     Samual @kins
> 
> <side track>: Is this part of the "get computers to understand people" idea ?

No.

It's an observation that "real" names can have more-or-less arbitrary
characters in them, especially spaces.

> The "more natural/human" is the WRONG goal; motivated by US-Disney
> and "the little man in the box syndrome".   

Wrong for what? Wrong why?

> "He almost understands me".
> Increased knowledge, reduces the apparent chaos/complexity of the
> universe into fewer rules/principles.  Progress = simplification.

If I were sloganising, "Progress = abstraction" would be more to my
taste. The real world is not simple, even if its underlying rules are
(and that's one of life's unknowns).

> Pop-11 has taken the wrong route (too late now) in having multiple
> syntaxes to say:
>     IF GreenBall NOT broken THEN ....

Why do you think Pop's taken a wrong route here? Do you mean to
suggest, for example, that it errs in having both `if` and `unless`
statements? Do you have empirical evidence to support this? I'm afraid
I can only offer personal, anecdotal evidence, which is that single-arm
conditionals with negative predicates are easier to understand using
`unless positive-condition` than 'if negative-condition'.

(Incidentally note the use of identifiers containing - signs.)

> The limitation on computing is the complexity, which overwhelms humans.

It's the *detail* that kills.

> Greater freedom (more "natural") equals greater complexity.

People master enormous amounts of complexity without apparent effort.
English is more complex in structure, and more flexible in semantics,
than any programming language I know of. Of course it's not as *exact*
without becoming very verbose.

> Lets not be driven/misled by MS-marketing   <end side track>

>> > My prefered OS (oberon) allows only alpha-numeric and 'period' for fileIDs
>> 
>> Oh, spit. That's ridiculous. No hyphens, underbars, plus signs, etc? I
>> think that's taking things to extremes I only dream (badly) of. I presume
>> you're allowed arbitrarily long filenames?
> MaxChar=31; I'm constrained by physical realities. eg. CharLenPerScreenLine

That's not a "physical reality", that's an arbitrary system restriction. 
There's no good reason for a name to be restricted to the length of a 
screen line (which in any case is ...  estimates ... about 160 characters, 
using my current font & the fat compile-my-project window).

>> > but files of other systems, with 'invalid' chars can be read,
>> >    by quoting. eg:  "c:/o236/file-name.htm"
>> 
>> So the file-system hadler accepts names with arbitrary characters, you 
>> just can't create files with them in? How ... strange.
>  I don't know the implementation details, but the native file system is
> optimised (life is about trade-offs) and to read/write DOS, Linux-based
> files the non-standard "patch" is used.

Well, it may be an "optimisation", but it optimises the wrong thing. It
turns out to be nice for people to give files long meaningful names. It's
also nice for *programs* to be able to create files with long names
(such as 'map: int x int -> int') rather than having to implement 
(all over again) a mapping from nice long descriptions to short file names.

>> > Is this matter related to pop11's failure to detect the missing separator
>> > in the local var. declaration, below ?  My understanding is that comma
>> > (only) is a a valid separator here ?
>> > 
>> >     define listify(list) -> result;
>> >               vars next   tail;
>> 
>> HELP VARS says:
>> 
>>     For the present, commas may be omitted except after an initialisation,
>>     but it is recommended that they be used.
> Thanks. That reduces a very uncomfortable feeling.
> But I find such ambiguity unacceptable in computing.

Why? 

I'd prefer that the comma be mandatory, myself, but for robustness, not
because of some prejudice about ambiguity. (It's also not ambiguous;
there's a single meaning, with a *choice* of syntax.)

>> and I'd assume it's mostly a backward-compatability relic from the days
>> of POP2.
> These apparently trivial details cause 'failure'.

Of what?

Actually, I agree that apparently trivial details can turn out to be
important in language syntax. The one above is not, I think, one of
those cases.

>> No, there's no relationship between the one and the other.
> 
> Aaron wrote:-
> 
>> (c) My own feeling is that although the recent discussions of syntax for
>> various types of data-constructing expressions are interesting and
>> could, if they had occurred around 1970, have led to much better syntax
>> for the pop family, they are far less important for real users than
>> other "semantic" issues like the availability of powerful libraries that
>> extend what you can easily do, the availability of new debugging and
>> development tools, etc.
> 
> Yes, consider the cost/benefit.  The discussed changes seem to me
> (a beginner) to be drastic, hence potentially disasterous.

I am not myself proposing significant changes to Pop's syntax, although
I *do* think we should seriously reconsider our quoting conventions.
The syntax I have mentioned is that of existing experiments grounded in
my experiences using Pop11. 

As Jonathan alluded to, the reality is that if a language does not
change, it dies. Some changes have to be drastic to make progress.

>> By comparison with "semantic" extensions of the above types, I believe
>> changes to the syntax of existing constructs are really of marginal
>> importance!
> 
> Very important, marginal value, hence not recommended to change.
> ...

For existing Pop11 code, that's very likely the best route. But if Pop
is to continue to evolve, then we should consider *how* it should evolve
for best effect.

Part of that is syntax; part of it is the Poplog VM. The latter controls
what kind of things can be said; the former controls how *easily* they
may be said. For example, Pop's syntax for closures is pretty easy to
write and read; it gets used a *lot*. It's not perfect (I think Spice
"holes" will turn out better, but they've not been used in anger), but
it's easier than explicit lambda-expressions. If it's clumsy to write,
*it doesn't get used*.


-- 
Hedgehog