HDTenEightyP/NetNews huggingface dataset:
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.lang.misc
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Date: 16 Apr 92 09:54:03 GMT
	<STEPHEN.92Apr11043808@estragon.uchicago.edu>
	<1992Apr13.194947.17250@newshost.lanl.gov>
	<STEPHEN.92Apr14171919@estragon.uchicago.edu>
	<ROCKWELL.92Apr15002308@socrates.umd.edu>
	<STEPHEN.92Apr15014148@estragon
Organization: University of Chicago CILS

yIn article <ROCKWELL.92Apr15214305@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|Stephen P Spackman:
|   Obviously, I meant 32767 (that or I meant max). The point is that
|   the maximum for the representation and the maximum for the type are
|   different notions, and that in any case (no matter what IEEE may
|   tell you) "infinity" is not an integer and it's not a float. It's a
|   domain extension, and you shouldn't have to rely on them in order
|   to code up simple notions like min and max.
|
|So use the maximum for the type.
|
|If you wish to exclude certain representations, there will still be a
|maximum element among the representations you allow.

Not safe in the presence of conversions. And, unless your type was
specified by the user choosing bounds of hir own, a dangerous
confusion of the implementation with the object. Finally, how does
this solution work with bignums?

All in all, not an acceptable engineering alternative, IMHO.
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.misc
Subject: Re: What is a type? (was Re: Fortran90 and Arrays)
Date: 10 Apr 1992 05:02:55 GMT
Organization: University of California, San Diego
NNTP-Posting-Host: lyapunov.ucsd.edu

bevan@cs.man.ac.uk (Stephen J Bevan) writes:
: In article <1992Apr8.180420.9294@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
:    The word `type' means any static attribute which is associated with
:    an identifier in such a way that _every_ occurrence of the identifier
:    in a given scope has that attribute.
: 
: Is this is a JLG definition or do others share this view?  It
: certainly doesn't match with what my idea of a "type" is.
: 
: 
:    The word `type' has no meaning at all if all attributes are
:    dynamically alterable.
: 
: I would have thought it did, the "type" is just the "type" at the
: particular time you look at it.  I'd consider this "dynamic typing".

Well in that case all you mean by "type" is some sort of "hidden value" that
hangs on with the object that affects what it means in any given
expression.  In other words, a "value" by any other name. In a real live
implementation do I have to store some variable that says what the "type" is
at any given time?  If so, then isn't it just another sort of value?  The
identifier, of course, is effectively a compound type, where one of the
subparts is some thing that specifies what type it is, and then the other
part is of course the conventional value of that object.  The "type" of that
object is the "value" of the type specifier.

A "type declaration" is then an assertion about the "special hidden value" of
the object.

Either something changes, or it doesn't.  When I write an identifier
is there _anything_ that I know "for sure" in a static sense that can
be computed at compile time?  In this way, "type declarations" are
assertions about correct program behavior that the programmer can
specify if desired.  I, along with JLG, believe that this is a good
idea in most circumstances.  Fancy global analysis inherently can
figure out less than what I can.  

For practical use, this 'special hidden value' might be a useful
do things that matches most problem domains, but please call a spade
a spade.

Perhaps this duality ought to be made explicit.

: Stephen J. Bevan				bevan@cs.man.ac.uk


Matt Kennel
mbk@inls1.ucsd.edu
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: What is a type? (was Re: Fortran90 and Arrays)
Date: 16 Apr 92 10:42:54 GMT
	<BEVAN.92Apr10173700@panda.cs.man.ac.uk>
	<STEPHEN.92Apr13034706@estragon.uchicago.edu>
	<BEVAN.92Apr14015933@panda.cs.man.ac.uk>
	<STEPHEN.92Apr15014937@estragon.uchicago.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: stephen@estragon.uchicago.edu's message of 15 Apr 92 06:49:29 GMT

In article <STEPHEN.92Apr15014937@estragon.uchicago.edu> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
   In article <BEVAN.92Apr14015933@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
   | ... Why can't I
   | punt on the issue and call the type field an instance of special
   | "type" which itself can't appear in the "type" field?  (Forgive me if
   | this is straying too far, but isn't a similar "trick" done in category
   | theory, where there are "small" and "large" categories?)

   (1) there are perfectly sound type theories with type: type (even if I
   don't personally understand why), as has been known for many years.

Like? (I'm not doubting their existance, I'm just enquiring which
theories your refering to)


   (2) you were claiming that every value has a type field associated
   with it, and the value of the type field is optimised out. So the
   content of a type field is a value. So it has a type field, which has
   a value. It was your idea, not mine....

I think this is _your_ interpretation of idea.  Why does the contents
of a "type" field have to be a "value" like any other "value"?  In the
above model it has special status as I've pointed out already.


   It happens that I think your analysis is perfectly reasonable on an
   intuitive level, and I normally think about it in almost this way, but
   I think it's crucial to insist that the process is founded somewhere:

I agree, but where does it end?  IMHO all you can do is base the
definition on another model in the hope that this is well founded.
However, all you are doing is punting the issue to the well
foundedness of that model.  Is there some basis which you would like
to propose about which there is no doubt about its soundess?  If so,
how is that model "grounded"?

Stephen J. Bevan				bevan@cs.man.ac.uk
Newsgroups: comp.lang.misc
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Organization: Traveller
	<STEPHEN.92Apr9220641@estragon.uchicago.edu>
	<1992Apr10.093445.26931@newshost.lanl.gov>
	<STEPHEN.92Apr10055926@estragon.uchicago.edu>
	<ROCKWELL.92Apr10223545@socrates.umd.edu>
	<STEPHEN.92Apr11050533@estragon.uchicago.edu>
Date: Mon, 13 Apr 1992 00:44:46 GMT

Stephen P Spackman:
   J is just too notationally FLABBY to deal with anything outside of
   its narrow floats-and-arrays outlook - which is why I say it is cut
   from the same cloth as FORTRAN.

Maybe.  But what does this mean?

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
Newsgroups: comp.lang.misc
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: What is a type? (was Re: Fortran90 and Arrays)
Organization: Los Alamos National Laboratory
Date: Fri, 10 Apr 1992 09:51:51 GMT

In article <BEVAN.92Apr9151907@panda.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
|> [...]
|>    The word `type' has no meaning at all if all attributes are
|>    dynamically alterable.
|> 
|> I would have thought it did, the "type" is just the "type" at the
|> particular time you look at it.  I'd consider this "dynamic typing".

Ok.  But what is your criterion for determining which properties of 
an object are `type' and which properties are just `value'.  I specified
an explicit criterion for deciding what constitutes type: those properties
which are permanently associated with a name (or function, expression,
etc.) regardless of run-time variations.

At both ends of the language spectrum, the definition I gave for type
is meaningless.  In pure functional languages, _no_ property of an
object is dynamic in a given scope.  So, by my definition, all
attributes (including those normally called `value') are type
attributes.  In a typeless language (say, SmallTalk for variation
in the discussion) all the attributes associated with a name can
be assigned.  So, by my definition, none of these attributes are
type attributes.  In between these extremes are the only languages
in which the word `type' is meaningfully distinguished from `value'.
In my opinion.

(The above is not quite true of SmallTalk.  The distinction between
a global variable and a temporary or local one is determined by the
syntax of the identifier - with globals starting with an initial 
capital letter and others beginning with a lower case letter.  So
this property qualifies as a type attribute by my definition.)

J. Giles
Xref: sparky comp.lang.misc:1693 comp.lang.functional:476 comp.object:1743
Newsgroups: comp.lang.misc,comp.lang.functional,comp.object
Subject: Types as first-class values?
From: oscar@cui.unige.ch (Oscar Nierstrasz)
Date: 13 Apr 92 16:50:54 GMT
Organization: University of Geneva, Switzerland

Can anyone provide any references to programming languages that
treat types as first-class values?

The sense of "type" that I mean is "a partial specification of behaviour".

If a type is meant to represent some distinguished set of "values",
that is, some subset of the universe of discourse (whether this be
data, ADTs, objects, functions, processes, etc.), then a type expression
can be viewed as a specification (predicate) that values may or may not
satisfy.  The kind of properties types distinguish should be (just) enough
to determine that values be used in a "type-safe" way [i.e., (partial)
functions are only applied to appropriate values; objects are never sent
messages that they will not understand ...].

So, for a type to be first-class:

1. you must be able to bind it to a variable, pass it around, etc.,
2. test whether a value satisfies it (and, if it does, be able to use that
   value in a type-safe way within the scope of the test),
3. produce new types from old at run-time by means of type-operators.

Any pointers would be appreciated.  I am especially interested in
functional and object-oriented languages that treat types as first-class.

NB: There is a theory of types as values -- or special kinds of functions,
called "retracts" -- introduced by Scott, but I do not think this has ever
been used as the basis of a programming language.

Oscar Nierstrasz

-------------------------------------------------------------------
Dr. O.M. Nierstrasz                 | Tel:    41 (22) 787.65.80
University of Geneva                | Fax:            735.39.05
Centre Universitaire d'Informatique | Home:           733.95.68
12 rue du Lac, CH-1207 Geneva       | E-mail: oscar@cui.unige.ch
SWITZERLAND                         |         oscar@cgeuge51.bitnet
-------------------------------------------------------------------

Newsgroups: comp.lang.misc
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Organization: University of Chicago CILS
	<STEPHEN.92Apr9220641@estragon.uchicago.edu>
	<1992Apr10.093445.26931@newshost.lanl.gov>
	<STEPHEN.92Apr10055926@estragon.uchicago.edu>
	<ROCKWELL.92Apr10223545@socrates.umd.edu>
	<STEPHEN.92Apr11050533@estragon.uchicago.edu>
	<ROCKWELL.92Apr12194446@socrates.umd.edu>
Date: Mon, 13 Apr 1992 05:17:06 GMT

In article <ROCKWELL.92Apr12194446@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|Stephen P Spackman:
|   J is just too notationally FLABBY to deal with anything outside of
|   its narrow floats-and-arrays outlook - which is why I say it is cut
|   from the same cloth as FORTRAN.
|
|Maybe.  But what does this mean?

It means 1960 has come and gone? It means that the language designer
shouldn't be dictating what are appropriate data types to the users?
It means, why are you quibbling with each other and not looking around
to see what NEW territory there is to explore?
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
Newsgroups: comp.lang.misc
Subject: Re: SGML ???
From: billk@hawk.uucp (Bill Kinnersley)
Date: Tue, 7 Apr 1992 00:49:18 GMT
Organization: Computer Science Dept, University of Kansas

In article <1992Apr4.170923.1153@uwovax.uwo.ca> 35002_2732@uwovax.uwo.ca writes:
: 
: does anyone know anything about SGML- standard generalized markup language?
: 
There's a newsgroup devoted to this language: comp.text.sgml.
:
: i need to learn how to markup a childrens' picture book and i can't find
: any practical information or manuals.
: 
Can't resist this:  "Everything You Need To Know You Learned in Kindergarten"

-- 
--Bill Kinnersley
  billk@hawk.cs.ukans.edu
226 Transfer complete.
Newsgroups: comp.lang.misc
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Subject: Re: What is a type? (was Re: Fortran90 and Arrays)
Organization: University of Chicago CILS
	<s37hvINN1j1@network.ucsd.edu> <BEVAN.92Apr10173700@panda.cs.man.ac.uk>
Date: Mon, 13 Apr 1992 08:46:59 GMT

In article <BEVAN.92Apr10173700@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
|In article <s37hvINN1j1@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
|   bevan@cs.man.ac.uk (Stephen J Bevan) writes:
|   : In article <1992Apr8.180420.9294@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
|   :    The word `type' has no meaning at all if all attributes are
|   :    dynamically alterable.
|   : 
|   : I would have thought it did, the "type" is just the "type" at the
|   : particular time you look at it.  I'd consider this "dynamic typing".
|
|   Well in that case all you mean by "type" is some sort of "hidden value" that
|   hangs on with the object that affects what it means in any given
|   expression.
|
|Logically this is true for most languages.  It is only in the
|implementation of certain languages that _static_ information from the
|program text can allow the "hidden value" to be optimised away.

Nononono! If this were an accurate description, then the type would be
stored in a field (possibly optimisaed away!) whose type was described
by a field of type ? and value "type", whose type is described by a
field of type ?? and value ?, whose type is described by a field of
type ??? and value ??, whose....

So you have to do an INFINITE amount of optimisation to get a finite
programme.

But infinite optimisations and infinite programmes are, um, tricky
formal objects. Are you really *sure* this is how you want to approach
the issue?

"Type" is the information that must be available BEFORE manipulating a
value. And it is always grounded somewhere: in the language
specification. The length of the chain between the spec and the bits
in the machine, may, however, vary according to your driving habits.
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
Newsgroups: comp.lang.misc
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Fortran90 and Arrays
Organization: Traveller
	<ROCKWELL.92Apr8001532@socrates.umd.edu>
	<1992Apr8.180420.9294@newshost.lanl.gov>
	<ROCKWELL.92Apr8164502@socrates.umd.edu>
	<STEPHEN.92Apr9214055@estragon.uchicago.edu>
	<ROCKWELL.92Apr10214059@socrates.umd.edu
	<STEPHEN.92Apr11045523@estragon.uchicago.edu>
Date: Mon, 13 Apr 1992 00:42:28 GMT

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.

Stephen P Spackman:
>  |   Part of the reason, of course, is that there isn't enough of a
>  |   type system to resolve overloads.

Me:
>  |I'm not quite sure what this means.

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.

>  |   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.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
From: rys@apollo.inf.ethz.ch (Michael Rys)
Newsgroups: comp.lang.misc
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Date: 16 Apr 92 13:39:53 GMT
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH

In article <STEPHEN.92Apr16042133@estragon.uchicago.edu>, stephen@estragon.uchicago.edu (Stephen P Spackman) writes:

|> Hell no, it was an argument to a function and you get to choose it.
|> It's the APL guys who have trouble with this one. (Iverson once worked
|> out the solution to this, which is to give functions _attributes_ like
|> "identity" and "inverse", but I don't think it was ever implemented. I
|> thought it was cute, myself).

It was implemented in a language called AIDA (an APL descendant).
For more information see the language posting or contact

mgf@ipsaint.ipsa.reuter.com

Cheers
Michael Rys
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Date: 16 Apr 92 18:45:20 GMT
Article-I.D.: newshost.1992Apr16.184520.2059
Organization: Los Alamos National Laboratory

In article <ROCKWELL.92Apr15220419@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> The maximum element of a type is the identity element for the MIN
|> operation. 

Aren't you the one who keeps saying that the programmer shouldn't have
to deal with implementation specific issues - particularly hardware
related ones?  The intuitive meaning for MIN is that it has _no_ 
identity - it is used to compute the minimum of a non-empty collection
of values.  If the collection of values is empty - there is _no_
minimum element.  The minimum element of such an empty collection 
is certainly _NOT_ the maximum value of some implementation dependent
type - a value the collection didn't even contain.

|> [...]
|>    NAN (not a number) might be an appropriate return.
|> 
|> Are you saying that
|>    MIN(NAN, 5)
|> is 5?

No.  I'm saying that MIN() [that is, min applied to nothing] is NAN,
and that otherwise MIN is guaranteed to return a value that was actually
present in its argument.  Better than this would be for MIN() to cause
an exception - then you could _always_ assume that a return value was
a member of the argument collection.

For another thing, what's the identity element of MIN reduced on 
an empty collection of BIGNUMS (arbitrary sized integers)?  What is
the identity element for MIN reduced on an empty collection of
character strings (the infinite length string of whatever character
is at the end of your collating sequence?)?  For that matter, how do 
you determine the base type of an empty collection in your typeless 
language?  Does the empty collection contain no integers, or does it 
contain no arrays of complex, or perhaps is contains no character 
strings, or....

|> [...]
|>    The user should have control over this explicitly though.  The user
|>    should decide what should be done if the array argument to a reduce
|>    is empty.
|> 
|> If that's the case, the user can do so... [obligatory description of
|> turing completeness elided].

Cute, but you haven't specified _how_ the user gets such control.
If it requires considerably different (longer) expressions to do so, 
then I claim your language is broken - the thing you want _most_ 
often (explicit control) should be the default behavior.  The less
common operation (if allowed at all) is the one that should take 
more complicated denotation.

J. Giles
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Modula-3, Fortran, Numbers & Aliens
Organization: Los Alamos National Laboratory
Date: Wed, 8 Apr 1992 18:08:53 GMT

In article <ROCKWELL.92Apr8002239@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> You misunderstand.  I was talking specifically about the case of
|> writing tools for generating and/or debugging code.  There is no
|> requirement that all languages must use system dependent features to
|> implement these sorts of tools.
|> 
|> Or are you saying that there are system-independent ways of
|> implementing these sorts of tools in Fortran?

Any such tools that are applicable to J could also be applied to 
Fortran to the same degree.  Debugging, for example, cannot be done
for either language in a system independent way unless you interpret
the source.  Source interpretation can be applied to Fortran.

J. Giles
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: What is a type? (was Re: Fortran90 and Arrays)
Date: 9 Apr 92 14:19:07 GMT
	<ROCKWELL.92Apr8001532@socrates.umd.edu>
	<1992Apr8.180420.9294@newshost.lanl.gov>
Organization: Department of Computer Science, University of Manchester
In-reply-to: jlg@cochiti.lanl.gov's message of 8 Apr 92 18:04:20 GMT

In article <1992Apr8.180420.9294@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
   The word `type' means any static attribute which is associated with
   an identifier in such a way that _every_ occurrence of the identifier
   in a given scope has that attribute.

Is this is a JLG definition or do others share this view?  It
certainly doesn't match with what my idea of a "type" is.


   The word `type' has no meaning at all if all attributes are
   dynamically alterable.

I would have thought it did, the "type" is just the "type" at the
particular time you look at it.  I'd consider this "dynamic typing".


   In this case you _may_ decide to apply the word `type' to certain
   properties of _values_, but such a distinction is not useful. 

Hm, I tend to think the same about the definition of "type" given
above.


   You have been juggling semantics rather creatively to claim that
   every assignment actually introduces a new scope.  If this is true,
   then it saps the meaning of the word `scope' to nothing.

Maybe I have it all wrong, but I have no problem with Raul's
definition.  Can't you just imagine a "let" in front of any
"assignment"? i.e.

   A =: B             let A = B
   ...                in ...
   A =: C                let A = C 
                         in ...

and use parentheses to delimit scopes as Raul showed in a previous
message.

Stephen J. Bevan				bevan@cs.man.ac.uk