HDTenEightyP/NetNews huggingface dataset:
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Date: 13 Apr 92 17:24:33 GMT
Article-I.D.: newshost.1992Apr13.172433.1633
Organization: Los Alamos National Laboratory

In article <ROCKWELL.92Apr10230632@so
|> [...]
|> J's style of programming _is_ a bit different than what is
|> traditionally used.  Where it shines is in applicative code:  [...]

Haskell is also vastly different from traditional languages.  Haskell
is a strict functional language - so it shines _MORE_THAN_J_ for those
applications where applicative programming is natural to the problem.

From what I can discover, the present Haskell implementations are also
more efficient than J - and are inherently so.  This is because J is
not purely functional.

|> [...]                                                      If
|> you've a specific problem space, it's usually possible to pick a dozen
|> or so operations which are particularly suited for describing problems
|> in that space.  [Which is what I presume you were talking about when
|> you said it seemed like a fancy calculator.]

No.  I was complaining about the `session' oriented flavor of interaction
with the language.  Instead of designing and writing programs which you 
proof-read before submitting, J encourages the sit-down-and-hack approach
to coding which never leads to reliable programs (of any size) in _ANY_
language.

J. Giles
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.92Apr10055926@estragon.uchicago.edu>
	<1992Apr10.184017.10041@newshost.lanl.gov>
	<STEPHEN.92Apr11043808@estragon.uchicago.edu>
	<ROCKWELL.92Apr12192640@socrates.umd.edu>
Date: Mon, 13 Apr 1992 05:25:41 GMT

In article <ROCKWELL.92Apr12192640@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|Stephen P Spackman:
|>  You are searching in a tree, and you want to use the natural tree
|>  structure and not get it flattened to a vector. I *don't* know of a
|>  language with a type structure in which this very practical problem
|>  can be made to drop out notationally though - but wait another five
|>  or ten years, and you'll see it cropping up. It'll look like an
|>  alternate interface that makes an automatic coercion (an interface
|>  inheritance, actually) unnecessary.
|
|This doesn't look like a difficult problem.  As I understand it, you
|wish a function which will take as arguments a tree, and keys to look
|for inside that tree -- then return the sub-trees indicated by those
|keys.  Just about any language should be able to deal with this.

Yeah, but they all require you to know WHETHER it's stored as a tree,
which is irrelevant. Except the object-oriented ones, which FORBID you
to know that it represents a list, which is at least as brain-dead.

|Now, what is meant by a random-order scan?  Using J's scan with this
|random order "cons reduce" operation, I get results like:
|   cons_reduce\ (1,3,5,7,9)
|1                
|(1,3)            
|((1,3),5)        
|(1,((3,5),7))    
|((1,3),(5,(7,9)))
|
|Maybe you want a grove of "trees" where the partial results are
|interdependent?  Or what?

No, you are right. I'm being stupid again. I keep thinking I've
finally figured out what scans are good for, and then realising that
in fact I want a cons-reduce after all. Random-order scan has a couple
of plausible definitions, but you are right, cons-reduce is the thing
you actually want (and that in turn is built out of a restructuring
operation and an (identity, in this case) constructor-substitution).
----------------------------------------------------------------------
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>
Date: Sat, 11 Apr 1992 02:40:59 GMT

Stephen P Spackman:
   Actually, one of my biggest criticisms of J is that it is one of
   the worst "reserved word" offenders I've seen: there is a large
   vocaublary of operator symbols allowed by J's lexical rules (like &
   and *:) and EVERY ONE of them is reserved. If this isn't foolish I
   don't know what is.

How about having reserved words which can not be distinguished from
identifiers by a casual user?  Also, a quick look at the back cover of
the working copy of the J language specification, I see slightly under
80 tokens [which includes all your reserved words].  80 words is not
outrageous for a computer language.

   Part of the reason, of course, is that there isn't enough of a type
   system to resolve overloads.

I'm not quite sure what this means.

   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.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
Newsgroups: comp.lang.misc
From: eb@felix.Sublink.Org (Enrico Badella)
Newsgroups: comp.lang.misc
Subject: CALICO: anyone using this language?
Date: 6 Apr 92 15:35:41 GMT
Organization: Soft*Star s.r.l, Torino, Italy

As the title states, I'd like to know if someone is using
this new OO language developed by AT&T.
What are the impressions?


-- 
Enrico Badella				Internet: eb@felix.sublink.org
Soft*Star s.r.l.			          eb@icnucevx.cnuce.cnr.it
Via Camburzano 9			Phone:    +39-11-746092
10143 Torino, ITALY			Fax:      +39-11-746487
Newsgroups: comp.lang.misc
From: holen@xilinx.com (Victor A. Holen )
Subject: lang comparison (not war)
Keywords: icon eiffel c++ smalltalk mainsail
Organization: Xilinx Inc.
Date: Thu, 9 Apr 1992 23:15:15 GMT

I repost it here on sugestion that this may be the most appriopate group for it

Is there somewhere (book, ftp, ...) a reasonably objective 
comparison of icon with eiffel with a few other (perhaps c++,
smalltalk, mainsail..). Comparison of features, robustness ( 
maturity of compilers), clarity in use, availability, standard-status (!),
development environment (debuger +...), performance, suitability for
large CAD (and  other) projects ..   ?
Just the basics :)  ?
Thanks.
-- 
 victor ....  ___  ._..  .  _.     holen@xilinx.com


-- 
 victor ....  ___  ._..  .  _.     holen@xilinx.com
Newsgroups: comp.lang.misc
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Static scoping in J.
Organization: Traveller
Date: Tue, 7 Apr 1992 05:24:38 GMT

Theo Norvell wrote in response to one of my posts on the scope of J,
and tacitly encouraged me to post a response.  Below is his letter and
my response.

>  >Have I left any situation uncovered?

>  Hi.  The acid text for static scoping is usually something like
>  this: 

>          var A
>          A := 0

>          function whatIsA
>                  return A
>          end

>          function acidTest
>                  var A 
>                  A := 13
>                  return whatIsA
>          end

>          A := 7

>          acidTest  -- 7 gives static scoping, 13 gives dynamic scoping,
>                    -- and 0 is something a bit unusual.

>  How would this example look in J?  What would be the answer?

Well, one way of coding this in J might be
   A =: 0
   whatIsA  =:   'A' : ''
   acidTest =:   ('A =. 13'; 'whatIsA 0') : ''
   A =: 7

then, when I execute
   acidTest 0
I get 7.

One side issue worth noting is that J requires that all functions take
an argument.  For pathological cases, like the above, where the
argument is not necessary, you still need to supply a dummy argument
to meet the syntactic requirements.  

By the way, an analogy to this syntactic rule is chemical bonding --
it is when chemicals join that energy is released.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Modula-3, Fortran, Numbers & Aliens
Organization: Traveller
	<1992Apr8.170023.1191@newshost.lanl.gov> <id.TBVO.HL6@ferranti.com>
Date: Tue, 14 Apr 1992 02:37:53 GMT

Jim Giles:
   > They are saying that every occurrence of an assignment introduces
   > a new scope and that the assignment was a _definition_ of the
   > variable.

Peter da Silva:
   That's what our friend at UMD is saying. I don't think he
   understands scope at all, and he's just muddying the waters with
   this sort of comment. Just as you are when you start mixing up
   types and names.

I think the problem here is that these words (scope, type, ..) have
different meanings when discussing different languages.  I've been
trying to use the words in a manner consistent with "the technical
usages I'm aware of".

Note that in discussions of functional languages, it has been usual to
say that every "assignment" introduces a new scope.  This is, of
course, a nonsensical statement in the context of procedural
languages.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: What is a type? (was Re: Fortran90 and Arrays)
Date: 14 Apr 92 00:35:20 GMT
Organization: U of Arizona CS Dept, Tucson

In article  <STEPHEN.92Apr13034706@estragon.uchicago.edu> Stephen P Spackman writes:
]
]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.

In the first place, the idea of the type of types can be made sound
and usable, it does not require any infinite work.  In the second
place, you have to distinguish between the abstraction and the
implementation.  Abstractly, you don't "store" the type anywhere, it
is just a function of the value.  Implementationally, the type may be
stored in a field, but then it is just an unsigned int, and recursive
types don't come into it.
-- 
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: Types as first-class values?
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Wed, 15 Apr 1992 00:49:47 GMT

Oscar Nierstrasz writes:
>Can anyone provide any references to programming languages that
>treat types as first-class values?
> 
(Jim Bowery) writes:
>Try SETL for starters.
> 
>Set theory defines the algebra of types you want.

I would have thought that any algebaraic system that allows you to
define algebaraic structures at run-time is treating types as first
class objects. For example defining a permutation group by specifying
generators at run-time is in essence creating a type that defines the
bahaviour of all elements of the group. In addition if you can then
compute properties of the group (eg: its order) than are you not
computing the properties of a type (since the group is a type)?

graham
--
Graham Matthews                 And it's true we are immune
Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
graham@maths.su.oz.au
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Date: 10 Apr 92 19:46:29 GMT
Organization: Los Alamos National Laboratory

In article <1992Apr10.184017.10041@newshost.lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
|> [...]
|> Interestingly, the Haskell standard prelude (while I have it in front 
|> of me from the last paragraph) only has one scan defined -  left to 
|> right with an explicitly required initial result:

Apparently, my copy of the Haskell document is old.  The newest version
gives four `scan' definitions corresponding to the four `fold' definitions
I gave last time.  Sorry for the confusion. (I should have asked, the
guy that wrote the standard prelude is within shouting distance of
my office.)

J. Giles
From: fs@cs.tulane.edu (Frank Silbermann)
Subject: Re: Types as first-class values?
Nntp-Posting-Host-[nntpd-8319]: caesar
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Date: Wed, 15 Apr 1992 15:00:59 GMT

In article <STEPHEN.92Apr14174618@estragon.uchicago.edu> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
>	I'm a little confused by the notion of type you are looking for:
>	the fact that you specify that you want a membership TEST suggests
>	that you're thinking of a set theory rather than a type theory at all
>	- types are properties of the expressions, not the values,
>	*even when the types are values themselves*.

I don't understand the significance of this distinction.
The extensional definition of a predicate is the subset
of the universe/domain over which the predicate is true.
So what does it matter whether we speak of an object having
a property, or whether we speak of an object being a member
of the set which defines the property?

>	Languages that provide first-class sets?  I'm not sure
>	how you could do that, unless you restricted yourself
>	to small finite sets a la SETL.

I added first-class sets to a higher-order lazy functional language.
Sets may be infinite, and may contain functions or even other sets.
However, I had to greatly restrict the _operations_ over sets.
(Essentially, I had to assume that my sets are recursively enumerable,
not decidable, and hence there isn't even a set membership test!
The functionality of these sets is, however, adequate to express
any 1st-order Horn logic program.  It may be published soon
in the Journal of Functional Programming -- I recently returned
my corrections to the proofs).  The language does _not_, however,
offer types as objects. 

------------------------------------------
Frank Silbermann	fs@cs.tulane.edu
Tulane University	New Orleans, Louisiana  USA
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Fortran90 and Arrays
Date: 13 Apr 92 20:09:25 GMT
Article-I.D.: newshost.1992Apr13.200925.19646
Organization: Los Alamos National Laboratory

In article <id.6DTO.VWK@ferranti.com>, peter@ferranti.com (Peter da Silva) writes:
|> [...]                    , I think your definition of
|> the word "type" is a little narrow. How about:
|> 
|> 	The word `type' refers to the set of operations that may
|> 	be performed on a collection of data.

You mean, like whether coercion to integer can be done without loss
of precision?  Things like that?  The thing is that _all_ attributes,
even those conventionally regarded as `value', effect the set of
operations that may be performed on the data.  I can define an operation
which will only work on prime-number arguments - does this make primeness
a `type' attribute?

Once again, your definition doesn't actually specify any criterion for
deciding which attributes of the data are `type' and which aren't.  You
can _arbitrarily_ select a few kinds of attributes which you will call
`type' if you want to.  What purpose will such an exercise serve?

J. Giles
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Date: 13 Apr 92 17:51:00 GMT
Article-I.D.: newshost.1992Apr13.175100.3711
Organization: Los Alamos National Laboratory

In article <ROCKWELL.92Apr11011857@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|>
|> [... Very long example demonstrating exactly why I dislike J ...]

In fact, I don't see any reason for further comment on this particular 
issue.

J. Giles
Newsgroups: comp.lang.misc
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Fortran90 and Arrays
Organization: Xenix Support, FICC
Date: Tue, 14 Apr 1992 20:40:52 GMT

In article <1992Apr14.083505.9432@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
> Type punnung is illegal in ANSI C.  Casts of pointers to/from anything
> but (void *) is undefined.  Unions (when used for punning) are undefined.

So type punning is *undefined* in ANSI C, not *illegal*. Please be more
precise. There are very important differences between illegal, undefined,
and implementation-defined. Which do you mean here?
-- 
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX  77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
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.92Apr10055926@estragon.uchicago.edu>
	<1992Apr10.184017.10041@newshost.lanl.gov>
	<STEPHEN.92Apr11043808@estragon.uchicago.edu>
Date: Mon, 13 Apr 1992 00:26:40 GMT

Stephen P Spackman:
>  You are searching in a tree, and you want to use the natural tree
>  structure and not get it flattened to a vector. I *don't* know of a
>  language with a type structure in which this very practical problem
>  can be made to drop out notationally though - but wait another five
>  or ten years, and you'll see it cropping up. It'll look like an
>  alternate interface that makes an automatic coercion (an interface
>  inheritance, actually) unnecessary.

This doesn't look like a difficult problem.  As I understand it, you
wish a function which will take as arguments a tree, and keys to look
for inside that tree -- then return the sub-trees indicated by those
keys.  Just about any language should be able to deal with this.

Of, maybe you wish an operation which will take a matching function,
instead of a key?  Or maybe references to matching functions?

>  |For example: let's scan addition across an list of integers
>  |(1,3,5,7,9).  What happens if the result is (16,8,5,15,25) [I
>  |summed from the middle element out, alternating left and right]?
>  |Is this meaningful to any algorithm you know?

>  You need to use "cons" instead of "+" to see how it might be
>  interesting - "+" has the wrong algebraic properties for this
>  operation, and that ought (in principle) to be a static type error.

Using a "cons" like operation, instead of "+" here's a few examples of
random-order reduction on the above list:
   cons_reduce (1,3,5,7,9)
((1,3),(5,(7,9)))
   cons_reduce (1,3,5,7,9)
((((1,3),5),7),9)
   cons_reduce (1,3,5,7,9)
((1,((3,5),7)),9)

Now, what is meant by a random-order scan?  Using J's scan with this
random order "cons reduce" operation, I get results like:
   cons_reduce\ (1,3,5,7,9)
1                
(1,3)            
((1,3),5)        
(1,((3,5),7))    
((1,3),(5,(7,9)))

Maybe you want a grove of "trees" where the partial results are
interdependent?  Or what?

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
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.92Apr11043808@estragon.uchicago.edu>
	<1992Apr13.194947.17250@newshost.lanl.gov>
	<STEPHEN.92Apr14171919@estragon.uchicago.edu>
	<ROCKWELL.92Apr15002308@socrates.umd.edu>
	<STEPHEN.92Apr15014148@estragon.uchicago.edu>
Date: Wed, 15 Apr 1992 14:40:37 GMT

Stephen P Spackman:   (sorry about messing up attribution, earlier)
   |   ||> [... reduction on empty array ...]
   |   ||> Nono, you missed the point. Some operations (like "+") make
   |   ||> SENSE for empty arrays, and there you supply the
   |   ||> appropriate value (0). Others (like "min") only make sense
   |   ||> on an empty array in an extended domain (for present
   |   ||> purposes: don't make sense) and so you REQUIRE at least one
   |   ||> element, ...

Me:
   |I've been hoping some one else would bring this up, but: what kind
   |of implementation is this, where you've got a numeric type but no
   |maximum element of that type?  I wasn't aware that could happen
   |with a finite set of numbers -- at least, not for the case where
   |those numbers are members of the set of real numbers.

   That's not the point. The point is that if I say min({}) and you
   say -32768, you are WRONG.

No kidding.  If your system, or your implementation of sets, only
allows 16 bit signed integers then the answer should be 32767.  If
your system allows ieee floating point, then the answer should be
positive infinity.

You're right, it's trivial to show that -32768 is not an identity
element, try min(0, -32768).  But I don't see why you think that
-32768 is a maximum element for your numeric type.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Modula-3, Fortran, Numbers & Aliens
Date: 13 Apr 92 17:34:14 GMT
Article-I.D.: newshost.1992Apr13.173414.2319
Organization: Los Alamos National Laboratory

In article <ROCKWELL.92Apr10233251@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> And, I don't know about you, but to me it seems kind of silly to
|> introduce a "safety mechanism" that entirely ignores the big picture.

With respect to large scientific/numerical programs, this safety
mechanism _IS_ the big picture - or a large part of it anyway. 
It seems silly to me to introduce automatic generality to arbitrary
rank arrays or arbitrary data types when such generality ignores 
the big picture - which is that few algorithms are stable (or even
possible) in such generality.  An algorithm which is fast and
numerically stable on 2-d meshes may not even generate the right 
_sign_ bit on 3-d meshes - or may be _very_ slow to converge.
In such a regime, J ignores the important points and provides
irrelevant features.

J. Giles
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.misc
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Date: 13 Apr 92 06:29:26 GMT
Organization: University of California, San Diego
NNTP-Posting-Host: lyapunov.ucsd.edu

stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
: 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?

All data types are equal, but some are more equal than others.

Matt
mbk@inls1.ucsd.edu