🚀 go-pugleaf

In article <1992Apr16.211503.20555@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
||> [...]                      Anyway, you can drop arrays from your list of
||> useful primitives.  They're just funtions that return lvalues.
|
|Ha, Ha, Ha, Ha, Ha, Ha, Ha, Ha, ....  Try selling that to users who need
|to use them!  A physicist dosn't know or _care_ that these concepts are
|equivalent in the abstract thoughts of computing scientists.  A physicist
|shouldn't _need_ to know or care about this either.  What he wants is
|a convenient notation to represent algorithms of interest to him.  This
|does not mean he wants some minimalist notation which satisfies some
|esthetic urges of a computing science theorist.

Odd that you say this. C makes a distinction, but as I recall FORTRAN
traditionally uses the same notation for both. The only difference I
seem my comment making to a language is that the declaration would end
up doing something like placing the word "array" after an equals sign
instead of as part of the type. Big deal.

Just pointing out that your list had redundancies as well as omissions
:-).

|He shouldn't.  He has a much more pressing thing to worry about - he has
|to provide features and notations which his customers _WANT_, find 
|easy to use, debug, and maintain.  This will automatically lead to 
|a variety of languages targeted at different user communities. 

Send 'em back to school. A language is not that hard to learn. (-: The
traditional stories about dealings with faries all revolve around
their giving you what you ASK for and not what you NEED. :-)

|A notation for arrays as easy to read and use as the present intrinsic
|notations will be another intrinsic notation of _something_.  In fortran,
|array indexing is not distinguishable from a function reference with
|integer arguments - except that functions aren't usually associated with 
|any _extents_ in their domains and cannot have individual elements
|reassigned.  Come up with a function notation which allows those
|extra things and your function == array idea will be the same as
|the present (Fortran 77) special syntax.

My point. Thankyou. They "conflict" notationally and this is an ASSET.
In this case it works because they're the same thing anyway, but come
right down to it about half the things you're interested in while
computing are the same thing as a function call anyway.

|Of course, there is still a desire for `whole array' operations and
|`array slices', etc. - so your functions will have to be extended to
|allow for that legibly before anyone will be the least bit interested.  

Use whatever notation you were comtemplating for arrays and make it
legal for functions. The problem is solved! Ta-dah. Just by not being
defeatist.

[type as values claimed damaging. Recent sources offered]

|I'll get a list and post it early next week.

Much obliged.

||> [...]             Can I introduce control constructs with the same
||> relationships to my types that IF has to Booleans or FOR has to
||> Integers?
|
|No.  The discussion so far hasn't mentioned control constructs _at_all_
|since they are not types, operators, or anything else that's been 
|associated with this thread.

They turn out to be very nearly isomorphic, and there is an intimate
relationship between IF and Boolean and between FOR and Integer such
that they practically codetermine one another. I don't think these are
separable concerns. Note that SETL has finite-set-specific control
constructs. APL provides things like / which are array-based control
constructs. I'm not trying to pull a fast one here! :-)

|My definition of "keyword" (in common with most) is that it's an
|identifier which has built-in meaning at the _syntactical_ level of
|the language.

Certainly it seems to have a different flavour in lisp. I would have
used the same name for one of the selector components in smalltalk. I
think a keyword is a delimiter that follows rules like an identifier.
In any event, it doesn't much matter, since I think my point holds
under my definition, and the practical appearance for the user is the
same (in an appropriate language).

|So, what you want is not to define new keywords at all, you want to 
|define new flow control constructs.  And no, our proposal as it stands
|does not allow that.  The question is, what benefit does it offer
|above what we _do_ offer:
|
|	 i = .AT. <time> .DO. <expr> .END.

Excuse ME! Why did you add an "i =" in front of my example? There's
below the belt and below the belt, but editing my example so that it
makes no sense is going a little far even by the usual conventions of
net.debate....

|Since we don't advocate so called "expression languages", a statement
|is a different thing than an expression.  Assignment is a statement
|level operator, not an expression level one.  Further, an expression
|cannot stand alone as a statement - you've got to do _something_
|with the value of the expression.  (I suppose you _could_ define
|.AT. to be a prefix assignment operator which throws away its 
|argument or you could define it to be a procedure call which 
|returns no value.)

It happens that my language is an expression language and yours is
not, yes. So I politely offered you an example that was a
Void-expression, syntactically and semantically indistinguishable from
a statement, and YOU aded the assignment in front. I don't know if you
have asynchronous events yet, but I thought it fairly likely, so
that's why I suggested what I did (if you don't, change AT to UNTIL,
and have it be some kind of time-controlled loop. It's just a little
less compelling).

||> [...]
||> I repeat: I have never once suggested changing the SYNTAX of the
||> language. Not since I was twenty have I made such a suggestion (though
||> there are perfectly good and readable languages that provide some
||> capabilities in that direction, as it happens. I just don't like them,
||> for much the reasons you give: the cognitive load is a bit steep if
||> the programmmer makes a bad choice along the way).
|
|Well, if you can show the need, I'll consider it.  But, as far as I can
|tell, there is no need.  It is simpler to implement a language in which
|all flow control _syntax_ is fixed within the language design.  For most
|procedural languages, flow control is intimately bound to syntax in ways
|that types, operators, and variables are not.  This insures (among other
|things) that the most common flow control features are properly nested.

I repeat: I have never once suggested changing the SYNTAX. Are you
reading what you are quoting AT ALL?

In any event, you are wrong. Flow control *is* intimately bound to all
the operators. Look inside your compiler. See how the multiplication
is moved out of the loop and an addition appears inside it? See how
conjunction materialises as a branch?

|Gee, I would never use float for banking.  That's one problem domain
|where correctness (down to the very last bit) is more important than
|speed.  Further, there are no dynamic range problems in banking.  All
|calculations are aimed at the same fixed-point precision (usually 
|a thousanth of a dollar or less).  Or am I behind the times on 
|common banking practices?

Nope. I've just met some stupid people. I didn't expect you'd agree
with them! :-)
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------