🚀 go-pugleaf

In article <ROCKWELL.92Apr12194228@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|Stephen P Spackman:
|>  How about having NO reserved words?

|Easy to implement, though I'm not sure what the benefit is.  If you
|want to go even further "out there" you might consider methods to
|dynamically alter the parser's word-formation rules -- but again, I
|don't see the benefit.  Certainly, it would be strange to find that
|
|  IF (X = 1) THEN PRINT Y;
|
|meant 'compute the set intersection of the sets named ) and THEN, and
|store the result under the name ;'.
|
|And it would be even stranger to find that the whole line was a single
|identifier.

I'm NOT suggesting having no fixed syntax (there are very GOOD reasons
not to want that, including implementability and readability). Just
that if I want to write a function called

	"if ... represents ... then ... end"

the fact that there is one called

	"if ... then ... else ... end"

in the language core shouldn't stop me. Surely you see the difference?

An added benefit of this approach is that, given a syntax that is
INDEPENDENT of the actual identifiers, you don't even have to know the
full set of CORE language facilities to start reading code - the
opposite situation from PL/1 !

|Stephen P Spackman:
|>  Just that since there are no static types, and very, very few
|>  dynamic ones, it's hard to reuse a symbol: * couldn't be used for
|>  set intersection because you can't tell if a vector is intended to
|>  be interpreted as a set or not - that isn't recorded anywhere. So
|>  operators are in VERY short supply. Which is why there need to be
|>  so many squiggles, and why Iverson needs them all for himself :-).

|Operators are not in short supply -- or maybe you're using a different
|definition of "operator" than Jim Giles?  I could easily define an
|operator named FIND_SET_INTERSECTION, for example.

I was using it in the sense of "lexical operators", things that are
made up of punctuation marks and LOOK like operators. I must admit
that I have a strong bias against needing to look for something's
definition (either as a human or as a machine) before I can parse the
expression it appears in.

|>  |   But it seems really silly to say "these are my letters and
|>  |   those are yours" and make it impossible to build
|>  |   application-specific notation within the language.
|>  |
|>  |I haven't a clue what this means.

|>  I mean that it is none of the application programmer's business
|>  which functions are "built in" to the language, and which comes
|>  from a library that the system architect has provided. So there
|>  shouldn't be a syntactic distinction - it gets in the way of doing
|>  the job.

|But, there is no syntactic distinction.  There is a rhematic
|distinction (the word formation rules are different), but I just don't
|see why this is bad.

Because it distinguishes what is in the "core language" from what is
not. Which means that for applications using NEW datatypes we need a
NEW language which re-assigns the terse and convenient notations to
these new crucial types, and thast is really stupid when the same
language with a type system could have done just as well. You're
saying "if your types are other than characters and floats, go
elsewhere; this languiage is not for you". How silly!
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------