HDTenEightyP/NetNews huggingface dataset:
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>
Date: Sat, 11 Apr 1992 04:06:32 GMT

Jim Giles:
   By the way, at this point I've spent about the same amount of time
   studying Haskell as J - cumulatively about five hours each.  I find
   Haskell much more legible and easy to use (which isn't saying
   much).  Given that Haskell is a strict functional language and J
   isn't, if the argument is that there is an advantage to functional
   programming, then Haskell must be better according to that measure.

You've left out an important piece of information:  how did you study?

J's language spec isn't a good place to start -- it's a reference
manual.  It's better to go with something written to teach the
language (and it's also good to have a machine to play with the
concepts).

J's style of programming _is_ a bit different than what is
traditionally used.  Where it shines is in applicative code:  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.]

J falls down when you're trying to present "traditional programming
concepts".  J just isn't efficient enough when you use it to emulate a
traditional language.  It can do recursion and iterations and all that
sort of thing -- but there's a heavy slant towards solving the general
case of a problem instead of solving the specific case.  And, for lots
of people, "that just ain't the way things are done around here".

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Modula-3, Fortran, Numbers & Aliens
Organization: Xenix Support, FICC
Date: Mon, 13 Apr 1992 17:31:00 GMT

In article <ROCKWELL.92Apr8151628@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
> In a sense, this is true, but I think it misses a big issue:  there is
> a major distinction between 'type' and 'storage class'.

Sure is. And you're confusing things again...

> 'storage class' is a concept used when talking about the machine
> representation of data.

No, it's used when talking about the lifetime of data, as opposed the scope
which refers to the lifetime of an identifier. For example, objects created
on the stack in a conventional programming language have a lifetime limited
to the duration of that stack frame. Two different machine types (what you're
referring to as storage classes) may have the same storage class. For example:

	int foo(void)
	{
		int a;
		double b;
	}

The variable a has machine type "int", type "integer", scope "block",  and
storage class "automatic".

The variable b has machine type "double", type "floating point", scope "block",
and storage class "automatic"

	      SUBROUTINE FOO
	      INTEGER A
	      REAL*8 B
	      END

Here A and B have storage class "static" and scope "function".
-- 
/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
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Modula-3, Fortran, Numbers & Aliens
Organization: Los Alamos National Laboratory
Date: Wed, 8 Apr 1992 22:41:12 GMT

In article <ROCKWELL.92Apr8151628@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> 'type' is a concept used when talking about, for instance, the domain
|> of a function.  For example, 'prime number' might be considered a
|> type.  Or, less arbitrarily, 'symetric matrix' might be a type.

Type is any static information which the user and/or the compiler can
use to double check program correctness and enhance optimization.  If
an attribute of an object (whether it be a function or data) is not
static, then that attribute is part of the _value_ of the object and
not part of its _type_.

|> [...]
|> 'storage class' is a concept used when talking about the machine
|> representation of data.  This might be considered a 'type', but only
|> when discussing low-level function, or partial functions, on that
|> machine.

Storage class is often (but not always) desired to be part of the
type of an object.  J appears not to permit objects to be declared
to be limited to a specific storage class.  In fact, it's still not
clear to me that there are _any_ attributes about an object that can
be statically declared.

|> [...]
|> Forcing the programmer to concentrate on machine specific types is not
|> a good way to encourage robust or portable code.  [...]

Nor does disallowing the user access to those attributes.  In fact, due
to the nature of floating-point, _not_ letting the user have control
over machine specific attributes may make robustness unattainable.

|> [...]
|> This is a complex issue.  I don't think it's a good idea to remove
|> responsibility for this complexity from the language implementor (who
|> concentrates on porting the language to a specific machine) just to
|> dump it on the programmer (who concentrates on whatever arbitrary
|> problem domain she's interested in).  Not if it means the language is
|> less expressive...

Expressiveness is just exactly the issue.  J does not let me express
clearly those constraints that I know when I write the code.  Fortran
forces me to express constraints that I may want to leave up to the
compiler or which I may want the code to handle generically.  Our 
proposal is to allow the _user_ to decide which things to express and 
which not to.  In any case, Fortran is generally closer to what is 
needed from a general purpose tool than J is.  That's why out proposal
is based upon Fortran.

By the way, why do you assume all programmers are female?

|> [..]
|> On the other hand, if your goal is verbosity for its own sake, forcing
|> special case solutions is, in general, a good way to achieve it.

My goal is not `verbosity' but clarity.  Your goal appears to be
terseness.

J. Giles
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>
Date: Sat, 11 Apr 1992 03:35:45 GMT

Stephen P Spackman:
   What, you think I'm defending J, just because I don't like FORTRAN?
   They're practically dialects of each other anyway, with their
   array-o-centrism, type-o-phobia, line-oriented syntax,
   proliferation of system-reserved mechanisms, encouragement of
   semantically inexplicable floating-point arithmetic and general
   inattention to actually solving the problem....

I was going to let all that bs slide until you got to "general
inattention to actually solving the problem"....  What do you mean
general inattention to actually solving the problem?

Where in the world do you think J (or APL) get their reputation for
solving arbitrary problems in one line of code if they don't pay any
attention to problem solving?  The big reason I prefer J over a
language like Fortran is that I can develop code in J (or APL) a lot
faster than in a less structured language.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
Xref: sparky comp.lang.misc:1612 comp.unix.programmer:2296 comp.unix.misc:2000 comp.unix.sysv386:8404
From: pep@ambra.dk (Peter Pedersen)
Newsgroups: comp.lang.misc,comp.unix.programmer,comp.unix.misc,comp.unix.sysv386
Subject: PLZ compiler for UNIX
Summary: PLZ compiler for UNIX needed.
Keywords: PLZ compiler UNIX
Date: 9 Apr 92 16:14:24 GMT
Article-I.D.: ambra.1992Apr9.161424.20502
Organization: AmbraSoft A/S

We are looking for information regarding a PLZ compiler for UNIX preferable 
System VR4. 

If you have any information about where to get such a compiler either as
a commercial, public-domain product etc, please send me an email.

Thanks in advance.

Peter Pedersen
AmbraSoft Int. A/S
Copenhagen

pep@ambra.dk
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Date: 14 Apr 92 10:20:16 GMT
	<ROCKWELL.92Apr10230632@socrates.umd.edu>
	<1992Apr13.172433.1633@newshost.lanl.gov>
Organization: Department of Computer Science, University of Manchester
In-reply-to: jlg@cochiti.lanl.gov's message of 13 Apr 92 17:24:33 GMT

In article <1992Apr13.172433.1633@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
   Haskell is also vastly different from traditional languages.  Haskell
   is a strict functional language
        ^^^^^^

Lest anyone get the wrong idea about Haskell from the use of "strict"
above, I think a better way to characterise Haskell is (from the front
cover of the report :-) :- "a non-strict, purely functional language"

bevan
Newsgroups: comp.lang.misc
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Types, arrays, generality, and notation (was: Fortran90 and Arrays)
Organization: Los Alamos National Laboratory
Date: Wed, 15 Apr 1992 20:28:13 GMT

In article <ROCKWELL.92Apr15002308@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> Jim Giles:
|>    ||> [... 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, ...
|> 
|> 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.

Well, you quoted my name on someone else's remarks.  In fact, I was
disagreeing with the quote attributed to me above.  

As for maximum elements of a type, what has that got to do with the 
issues raised here?  The correct return of `min' applied to an empty 
is _not_ the maximum possible value of the type!  That implies that
the array wasn't empty but it's minimum element had that value.  NAN
(not a number) might be an appropriate return.  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.

J. Giles
Newsgroups: comp.lang.misc
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Modula-3, Fortran, Numbers & Aliens
Organization: Traveller
	<ROCKWELL.92Apr8231542@socrates.umd.edu>
	<1992Apr9.174123.19342@newshost.lanl.gov>
Date: Fri, 10 Apr 1992 04:33:37 GMT

Raul Deluth Miller-Rockwell:
   |> Well, in a very real sense, all objects except identifiers are
   |> statically declared.  [...]

Jim Giles:
   You mean, all objects except identifiers _and_ expressions involving
   identifiers.

Actually, I meant all objects except those which depend on i/o.
Which is a pretty significant exception, I'll admit.

   |> [...]  Also, there is a class of identifiers which may only be
   |> declared once.  [...]

   Really?  Please present the mechanism for doing this.

Use an alphanumeric identifier terminated by a colon.

   In particular however, I want the ability to declare identifiers to
   have _some_ fixed attributes and _some_ attributes that are allowed
   to vary.  For example, I want to be able to say that X is a scalar
   floating-point number - those characteristics of X are fixed for
   the life of the program - but I want the actual _value_ of X to be
   allowed to be changed.

Define yourself a verb to modify X.  If you're really paranoid, you
can write yourself a routine which does a static analysis of the
program text to find any instances where X is modified without the use
of this access verb.  If you need to do this sort of thing frequently,
you can call this routine a tool.

   |> [...] Finally, note that a compiler would likely create an
   |> object whose semantics are fixed.

   I don't know what you mean here.  The purpose of _any_ programming
   language is to define the semantics of an algorithm.  As such, the
   compiler always generates something with _some_ fixed properties.
   The question is whether the end user of the language has control
   over which properties are fixed and which aren't.

Yes.

I meant that if you compile a function to take only integer arguments
that you won't be able to pass to it arguments representing fractional
numbers.  The idea is that this is a restriction imposed during
compilation, and is not a property of the code.  Of course, you might
consider compiler invocation parameters to be code.

On the other hand, ain't no compilers of J written yet, so I'm
discussing vaporware, here.

   |>    Expressiveness is just exactly the issue.  J does not let me
   |>    express clearly those constraints that I know when I write
   |>    the code.

   |> It lets me express arbitrary constraints.  Of course, I have the
   |> advantage of having learned the language.

   Really?  Then you can tell me the very thing I keep asking and you
   keep dodging - how do I declare that a given identifier has a
   specific type for the life of the program - yet its _value_ can
   change?

I think I'd define an accessor verb.

Either that or just do a global search for all instances of that name
[though this seems, to me, more useful for maintenence than for
design].

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
Newsgroups: comp.lang.misc
From: harlan@pfcs.com (Harlan Stenn)
Subject: Re: "M" language
Organization: PFCS Corporation
Distribution: na
Date: Sun, 12 Apr 1992 05:28:57 GMT

"M" is an "official" alternate name for ANSI Mumps.

If you're looking for information about an implementation under Unix,
please let me know.

If you want information for other platforms, try contacting the Mumps
Users' Group in Silver Spring, MD.
-- 
Harlan Stenn  +1(314)230-8847
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.lang.misc
Subject: Re: Fortran90 and Arrays
Date: 16 Apr 92 16:11:52 GMT
	<id.OCVO.D6A@ferranti.com>
	<STEPHEN.92Apr14162524@estragon.uchicago.edu>
	<id.HHXO.DK9@ferranti.com>
Organization: University of Chicago CILS

In article <id.HHXO.DK9@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
|No, because one supports the operation "extract X co-ordinate" and the
|other supports the operation "extract distance from origin". You can
|convert one to the other, and this might be a transparent operation
|(apart from considerations such as execution speed), but they are not
|the same type.

If it's transparent then I can't accept this explanation. But I don't
have a better one to offer; I just don't know how to think about this
case yet.

[string comparison uses numeric char order]
|Right, so you have a non-portable (that is, dependent on undefined
|behaviour) routine. In general you want to avoid this, so you hide
|this sort of code behind a subroutine interface. At least if you're
|smart you do.

But the *compiler* is justified in doing it, as is the library writer
(assuming that se knows what the character code is). I stressed the
word LEGITIMATE. The caller doesn't know, the routine does, by hypothesis.

|C is, by the way, not a good language for illustrating types because
|issues of type, machine type, storage class, and even scope are all
|muddied (for example, the same keyword is used to define static storage
|class and file scope). All you hot compiler hackers, come out with some
|good compilers for your language I can cheaply bootstrap and I'll dump
|C like a hot potato.

Workin' on it. But C is a good medium for discussing *implementations*
even if it's a lousy source language, precisely because the grunge shows.

[high tech data selection]
|Tough to do in C. Impossible to do portably. But sounds like a good way
|to do things in a higher level language. In C you would have to create
|a set of accessor macros that did appropriate tests and coercions, and
|fix the implementation up for each new platform (for example, on the 286
|it's very easy for a string to compare numerically less than 0).

Seriously trying to meet your challenge, you understand. I don't want
to have to write Mythos in C....

Portability isn't a problem either, unless your code generator, God
forbid, is hand-coded....
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
Newsgroups: comp.lang.misc
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Subject: Re: Fortran90 and Arrays
Organization: University of Chicago CILS
	<1992Apr15.233338.3786@yrloc.ipsa.reuter.COM>
Date: Thu, 16 Apr 1992 10:12:32 GMT

In article <1992Apr15.233338.3786@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
|  Morgan Stanley Bank in NYC runs a foreign exchange trading system 
|  under SHARP APL. On Black Monday a few years ago, trade volumes and
|  $$ were so high that most systems either died (overflow) or got
|  drastically behind, giving their traders Very Bad Data, causing said
|  traders to trade themselves (and their firms) much further into the
|  red. Morgan's APL-based system not only didn't die (integers went to
|  real instead of getting integer overflow death), but the system didn't
|  fall behind, AND Morgan made a profit that day! 

This is a practise that will LITERALLY send you to prison in most
countries. Financial calculations MUST be performed to 100ths of a
cent (or whatever local law prescribes) and must NOT be rounded except
as permitted by law. I am literally shocked that you would consider
this a good solution to a practical problem.

|  The specification of "I'll make this integer because it'll run faster, 
|  and take less space, and I KNOW IT CAN't possibly overflow" school
|  was totally unprepared for the volumes traded that day. 
|  It simply was not thought possible. 

No, you make it an integer so that it will trap if it loses precision.
(-: Then again, maybe this is a business in which it's considered to
be better to be rich and in prison? :-).

|Where I come from, we get "index error". We also signal "index error"
|on things like indexing with negatives, or with numbers > shape of array
|axis, unlike C and Fortran. But that's only because we're silly types
|who care more about correct results than speed.

An interesting juxtaposition, since if you wanted correct results
rather than speed you'd use bignums and constructive reals.
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Modula-3, Fortran, Numbers & Aliens
Organization: Traveller
	<1992Apr6.193950.5862@newshost.lanl.gov>
	<STEPHEN.92Apr6203432@estragon.uchicago.edu> <id.KXOO.61F@ferranti.com>
	<1992Apr8.170023.1191@newshost.lanl.gov>
Date: Wed, 8 Apr 1992 20:16:28 GMT

Jim Giles:
   Whatever you call it, an identified may refer to something of
   different type in different parts of the program - something which
   I consider to be undesirable.

In a sense, this is true, but I think it misses a big issue:  there is
a major distinction between 'type' and 'storage class'.

'type' is a concept used when talking about, for instance, the domain
of a function.  For example, 'prime number' might be considered a
type.  Or, less arbitrarily, 'symetric matrix' might be a type.

'storage class' is a concept used when talking about the machine
representation of data.  This might be considered a 'type', but only
when discussing low-level function, or partial functions, on that
machine.

J will support the type 'symmetric matrix' in the same fashion it will
support the type 'integers in the range 32767 down to -32768'.

Forcing the programmer to concentrate on machine specific types is not
a good way to encourage robust or portable code.  Nor does it "force
the programmer to not change the type of an identifier" -- at least,
this is the case for problems where the machine type is only an
approximation of the desired type.

This is a complex issue.  I don't think it's a good idea to remove
responsibility for this complexity from the language implementor (who
concentrates on porting the language to a specific machine) just to
dump it on the programmer (who concentrates on whatever arbitrary
problem domain she's interested in).  Not if it means the language is
less expressive...

Anyways, in a sufficiently expressive language there is little need to
re-declare identifiers.  Re-declaring identifiers is only necessary
when you're explicitly dealing with time, and even there it's not
always necessary.  But to prevent such activity altogether requires
unwarranted assumptions about the problem domain of the programmer.
[And, since similar facilities are available in the operating system,
forces the programmer to system specific implementations when it might
not be necessary.]

On the other hand, if your goal is verbosity for its own sake, forcing
special case solutions is, in general, a good way to achieve it.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
The U.S. government went another thousand million dollars into debt today.
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Fortran90 and Arrays
Organization: Xenix Support, FICC
Date: Tue, 7 Apr 1992 22:19:05 GMT

In article <1992Apr7.174954.10303@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
> I consider J's treatment of type to be crippled.

We know.

You also like referring to J's typing system in Pascal terms, which is
as meaningless as using J syntax in Fortran programs.
-- 
/F{/Times-Roman findfont exch scalefont setfont}def /M{moveto}def /S{show}def
8 F 24 24 M (Sugar Land, TX  77487-5012; +1 713 274 5180)S 60 0 rmoveto(`-_-')S
12 F 24 32 M (Peter da Silva, Ferranti International Controls Corporation)S
0 -6 rmoveto 20 F ( Have you hugged your wolf today?)S showpage