> 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 ?
The "more natural/human" is the WRONG goal; motivated by US-Disney
and "the little man in the box syndrome". "He almost understands me".
Increased knowledge, reduces the apparent chaos/complexity of the
universe into fewer rules/principles. Progress = simplification.
Pop-11 has taken the wrong route (too late now) in having multiple
syntaxes to say:
IF GreenBall NOT broken THEN ....
The limitation on computing is the complexity, which overwhelms humans.
Greater freedom (more "natural") equals greater complexity.
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
> > 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.
> > 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.
> and I'd assume it's mostly a backward-compatability relic from the days
> of POP2.
These apparently trivial details cause 'failure'.
> 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.
Inevitably the greatest added value per effort (especially for beginnners
usage) is acheived by mundane tasks - which no one want's to discuss.
eg. "set up a system" (NOT do the job) whereby new users report typos
in the tutorials, which are fixed.
...
> 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.
...
> Is anyone interested in forming a collaborative project to provide
> the gsl extension to pop-11???
Are the extensions just mathematical facilities ?
Can you list some example(s) ?
Chris Glur.
|