Java 14 now have "Record" !

" records are meant to be data carriers"

https://www.digitalocean.com/community/tutorials/java-records-class

And Python 3.7 now has records, they call it "data class"

https://realpython.com/python-data-classes/

"One new and exciting feature coming in Python 3.7 is the data class.
A data class is a class typically containing mainly data"

What took them so long? Pascal and Ada had records
from day one, only 40 years ago or so.

--Nasser

On 5/12/23 13:50, Nasser M. Abbasi wrote:
>
> Java 14 now have "Record" !
>
> " records are meant to be data carriers"
>
> https://www.digitalocean.com/community/tutorials/java-records-class
>
> And Python 3.7 now has records, they call it "data class"
>
> https://realpython.com/python-data-classes/
>
> "One new and exciting feature coming in Python 3.7 is the data class.
> A data class is a class typically containing mainly data"
>
> What took them so long? Pascal and Ada had records
> from day one, only 40 years ago or so.
>
> --Nasser
>
And Cobol had them 63 years ago.

On 2023-05-12 19:50, Nasser M. Abbasi wrote:
>
> Java 14 now have "Record" !
>
> And Python 3.7 now has records, they call it "data class"
>
> What took them so long? Pascal and Ada had records
> from day one, only 40 years ago or so.

Pascal had them in 1970. Algol, I think, had them in 1960.

--
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

On 2023-05-13 0:33, Jeffrey R.Carter wrote:
> On 2023-05-12 19:50, Nasser M. Abbasi wrote:
>>
>> Java 14 now have "Record" !
>>
>> And Python 3.7 now has records, they call it "data class"
>>
>> What took them so long? Pascal and Ada had records
>> from day one, only 40 years ago or so.

Java and Python have classes, which have records as a special case, if
the term "record" is understood as in most other languages, including Ada.

But it seems that the Java 14 "record" is not quite the same as an Ada
record, because Java 14 records are meant to be immutable data carriers,
not mutable data structures. Still, Java 14 records are described as a
(very) special case of classes.

> Pascal had them in 1970. Algol, I think, had them in 1960.

Algol 60 did not have records, only arrays.

Algol W, a precursor to Pascal, had them in 1966.

Simula had them in 1967. (Wikipedia says "In 1966 C. A. R. Hoare
introduced the concept of record class construct".)

Algol 68 had them in 1968.

Pascal had them in 1970, as you say.

On 13/05/2023 08:13, Niklas Holsti wrote:

>> Pascal had them in 1970. Algol, I think, had them in 1960.
>
>
> Algol 60 did not have records, only arrays.
>
> Algol W, a precursor to Pascal, had them in 1966.
>
> Simula had them in 1967. (Wikipedia says "In 1966 C. A. R. Hoare
> introduced the concept of record class construct".)
>
> Algol 68 had them in 1968.
>
> Pascal had them in 1970, as you say.
>

What about COBOL and LISP?

On 2023-05-13 14:18, Luke A. Guest wrote:
> On 13/05/2023 08:13, Niklas Holsti wrote:
>
>>> Pascal had them in 1970. Algol, I think, had them in 1960.
>>
>>
>> Algol 60 did not have records, only arrays.
>>
>> Algol W, a precursor to Pascal, had them in 1966.
>>
>> Simula had them in 1967. (Wikipedia says "In 1966 C. A. R. Hoare
>> introduced the concept of record class construct".)
>>
>> Algol 68 had them in 1968.
>>
>> Pascal had them in 1970, as you say.
>>
>
> What about COBOL and LISP?

As I understand it (but I don't claim to be expert), the early COBOL
languages could describe the structure of file records, and of
working-storage objects, as nested sequences of components and
sub-records, but each such description defined a _single_ "record"
object, not a "record" data-type that could have many instances. So if
you wanted to have two record objects with the same structure, you had
to duplicate the whole record description.

However, Wikipedia says that the COBOL record structure inspired records
for Pascal.

Early LISP languages did not have record types, AFAIK. But you could of
course use lists to program record-like data structures.

Le 13/05/2023 à 18:53, Niklas Holsti a écrit :
>> What about COBOL and LISP?
>
>
> As I understand it (but I don't claim to be expert), the early COBOL
> languages could describe the structure of file records, and of
> working-storage objects, as nested sequences of components and
> sub-records, but each such description defined a _single_ "record"
> object, not a "record" data-type that could have many instances. So if
> you wanted to have two record objects with the same structure, you had
> to duplicate the whole record description.
AFAIR, COBOL didn't have types, but you could define a variable LIKE
another one.

> However, Wikipedia says that the COBOL record structure inspired records
> for Pascal.
>
> Early LISP languages did not have record types, AFAIK. But you could of
> course use lists to program record-like data structures.
Of course, in LISP there is only one structure, for data and programs
alike: the list!

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

On 5/14/2023 1:46 AM, J-P. Rosen wrote:
> Le 13/05/2023 à 18:53, Niklas Holsti a écrit :

>> for Pascal.
>>
>> Early LISP languages did not have record types, AFAIK. But you could of
>> course use lists to program record-like data structures.

> Of course, in LISP there is only one structure, for data and programs
> alike: the list!
>

This is similar to Mathematica. I programmed a little in lisp,
and it was kinda fun.

In Mathematica, its main data struct is also the list
and list of lists and list of list of lists and so on.

a={1,2,3};
a={{1,2,3},{4,5,6}};

Everything in Mathematica is pretty much build using lists.

Few years ago, Wolfram introduced Association, which
acts like a RECORD. It is really like a dictionary. It has
key->value pairs so one can do:

myData = <| "name"->"me","age"->99 |>

To read value of a field one uses myData["name"] or myData["age"].

It is amazing how people can program so much code
using only just a list as the main basic data structure
and be able to get away with it :)

I think RECORD is the most important data structure myself.

Without a RECORD (called struct in C), programming
is much harder. This is what Java and Python have discovered
just now. I guess the language designers of these
languages never bothered to look at Pascal or Ada before.

But better late than never I guess.

--Nasser

On 14/05/2023 07:46, J-P. Rosen wrote:

> AFAIR, COBOL didn't have types, but you could define a variable LIKE
> another one.
>
>> However, Wikipedia says that the COBOL record structure inspired
>> records for Pascal.
>>
>> Early LISP languages did not have record types, AFAIK. But you could
>> of course use lists to program record-like data structures.
> Of course, in LISP there is only one structure, for data and programs
> alike: the list!
>

TBH, I don't really remember anything of COBOL apart from pictures and
columns.

On 14/05/2023 07:46, J-P. Rosen wrote:

> Of course, in LISP there is only one structure, for data and programs
> alike: the list!

Well, that's not true anymore, especially not in common lisp which has a
variety of data structures including records, I was quite surprised to
see that when I was looking at it last year.

On 14/05/2023 08:20, Nasser M. Abbasi wrote:

> I think RECORD is the most important data structure myself.
>
> Without a RECORD (called struct in C), programming
> is much harder.  This is what Java and Python have discovered
> just now.  I guess the language designers of these
> languages never bothered to look at Pascal or Ada before.
>
> But better late than never I guess.

I think people might finally be realising that you can't do everything
with only one programming paradigm.

On 2023-05-14 9:46, J-P. Rosen wrote:
> Le 13/05/2023 à 18:53, Niklas Holsti a écrit :
>>> What about COBOL and LISP?
>>
>>
>> As I understand it (but I don't claim to be expert), the early COBOL
>> languages could describe the structure of file records, and of
>> working-storage objects, as nested sequences of components and
>> sub-records, but each such description defined a _single_ "record"
>> object, not a "record" data-type that could have many instances. So if
>> you wanted to have two record objects with the same structure, you had
>> to duplicate the whole record description.
> AFAIR, COBOL didn't have types, but you could define a variable LIKE
> another one.

So I also remembered, but (before writing the above) I looked through
some COBOL syntaxes on the net and could not find LIKE as part of the
data division syntax.

However, after more searching, I see that at least current Microfocus
RM-COBOL supports a "SAME AS" definition that has that effect. I don't
know when that feature was introduced. I did not find it in the current
IBM COBOL description.

In Microfocus RM-COBOL, the LIKE word can be used as a boolean relation
that compares the content of a variable to a pattern, like a regexp
match. I did not find this kind of relation in IBM COBOL.

Another way to clone a COBOL record structure is to put the record
structure description in a separate source-code file, and COPY that file
(like C "include") into the declaration of any object that should have
that structure. But ugh. And it could make a mess of the "level
numbers", where the RM-COBOL SAME AS definition adjusts those automatically.

"J-P. Rosen" <rosen@adalog.fr> writes:

> Of course, in LISP there is only one structure, for data and programs
> alike: the list!

LISP had S-expressions -- pairs of atoms or other S-expressions. A list
was just a special case. Many other structures could be built using
S-expressions. An important one was that association list -- a list of
(key . value) pairs that was often used very much like a record type
(though it's quite a different beast).

--
Ben.

On 2023-05-14 08:46, J-P. Rosen wrote:
>
> Of course, in LISP there is only one structure, for data and programs alike: the
> list!

In the LISP I learned, there were only S-expressions (SEXes). A SEX is either an
atom or a list of SEXes. Another way of putting it was there were atoms and
lists of atoms or lists. Either way, there were also atoms.

--
Jeff Carter
"Don't knock masturbation. It's sex with someone I love."
Annie Hall
45

On 14 May 2023, J-P. Rosen wrote
(in article <u3q03n$2iba1$1@dont-email.me>):

> Le 13/05/2023 à 18:53, Niklas Holsti a écrit:
> > > What about COBOL and LISP?
> >
> >
> > As I understand it (but I don't claim to be expert), the early COBOL
> > languages could describe the structure of file records, and of
> > working-storage objects, as nested sequences of components and
> > sub-records, but each such description defined a _single_ "record"
> > object, not a "record" data-type that could have many instances. So if
> > you wanted to have two record objects with the same structure, you had
> > to duplicate the whole record description.
> AFAIR, COBOL didn't have types, but you could define a variable LIKE
> another one.

LIKE is PL/I.

--
Bill Findlay

Le 14/05/2023 à 12:39, Jeffrey R.Carter a écrit :
> On 2023-05-14 08:46, J-P. Rosen wrote:
>>
>> Of course, in LISP there is only one structure, for data and programs
>> alike: the list!
>
> In the LISP I learned, there were only S-expressions (SEXes). A SEX is
> either an atom or a list of SEXes. Another way of putting it was there
> were atoms and lists of atoms or lists. Either way, there were also atoms.
>
Right, but I would define atoms as the basic data, not a data
/structure/. Oh well, just a matter of definition...
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> writes:

> On 2023-05-14 08:46, J-P. Rosen wrote:
>> Of course, in LISP there is only one structure, for data and programs
>> alike: the list!
>
> In the LISP I learned, there were only S-expressions (SEXes). A SEX is
> either an atom or a list of SEXes.

I never saw a LISP S-expressions defined that way. Did this list really
no have a "dotted pair" as the basic structure with lists being simply a
special case?

--
Ben.

On 2023-05-14 17:14, Ben Bacarisse wrote:
>
> I never saw a LISP S-expressions defined that way. Did this list really
> no have a "dotted pair" as the basic structure with lists being simply a
> special case?

The book I learned from (/Let's Talk LISP/ by Laurent Siklóssy, 1976) introduces
dotted pairs in chapter 10.7.1 (out of 12 chapters) on page 145 (out of 213,
excluding appendices and index). Chapter 10 deals with the internal
representation of data in LISP. The implication is that they were not considered
part of the normal use of the language.

S-expressions, on the other hand, are introduced in chapter 1.1 on page 2. The
book also presents the grammar

S-expression ::= atom | list
list ::= '(' inside ')'
inside ::= empty | S-expression | S-expression inside
empty ::=

--
Jeff Carter
"Don't knock masturbation. It's sex with someone I love."
Annie Hall
45

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> writes:

> On 2023-05-14 17:14, Ben Bacarisse wrote:
>> I never saw a LISP S-expressions defined that way. Did this list really
>> no have a "dotted pair" as the basic structure with lists being simply a
>> special case?
>
> The book I learned from (/Let's Talk LISP/ by Laurent Siklóssy, 1976)
> introduces dotted pairs in chapter 10.7.1 (out of 12 chapters) on page 145
> (out of 213, excluding appendices and index). Chapter 10 deals with the
> internal representation of data in LISP. The implication is that they were
> not considered part of the normal use of the language.

Do you still have it? Does is discuss association lists? I'd call them
a normal part of LISP and it would be odd to force the associations to
be lists rather than pairs. Does Siklóssy imply that an ASSOC list is a
list of lists of length 2, or does he not discuss them until the very
end?

> S-expressions, on the other hand, are introduced in chapter 1.1 on page
> 2. The book also presents the grammar
>
> S-expression ::= atom | list
> list ::= '(' inside ')'
> inside ::= empty | S-expression | S-expression inside
> empty ::=

That's an interesting way to simplify things for the leaner though I
would not have chosen to use a term that already had another meaning by
1976. The author could have used something like L-expression and
avoided any future confusion.

--
Ben.

On 2023-05-15 03:11, Ben Bacarisse wrote:
>
> Do you still have it? Does is discuss association lists? I'd call them
> a normal part of LISP and it would be odd to force the associations to
> be lists rather than pairs. Does Siklóssy imply that an ASSOC list is a
> list of lists of length 2, or does he not discuss them until the very
> end?

The Function ASSOC is discussed in Chapter 9 as an auxiliary function used by
EVAL (Chapter 9 discusses the working of EVAL). It says

ASSOC finds the value of a variable in the ALIST. The ALIST is a list of
sublists of two SEXes each of the form (variable value-of-the-variable).

In a footnote he notes that the ALIST could be a list of dotted pairs, which are
defined in the next chapter.

I never did much with LISP after learning it, and never looked at any other
textbooks, so he might have an idiosyncratic approach. Seems rather OT for c.l.a.

--
Jeff Carter
"Mixtures of similar characters (letter O and
digit 0, letter I and digit 1, etc.) are unsafe,
as are long identifiers that differ only at the
end."
Elements of Programming Style
187

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> writes:

> On 2023-05-15 03:11, Ben Bacarisse wrote:
>> Do you still have it? Does is discuss association lists? I'd call them
>> a normal part of LISP and it would be odd to force the associations to
>> be lists rather than pairs. Does Siklóssy imply that an ASSOC list is a
>> list of lists of length 2, or does he not discuss them until the very
>> end?
>
> The Function ASSOC is discussed in Chapter 9 as an auxiliary function used
> by EVAL (Chapter 9 discusses the working of EVAL). It says
>
> ASSOC finds the value of a variable in the ALIST. The ALIST is a list of
> sublists of two SEXes each of the form (variable
> value-of-the-variable).

Thanks. Is this a dialect made up for pedagogic purposes? I don't know
of any practical LISP that went down this route.

> Seems rather OT for c.l.a.

Yes, it is. Happy to stop. I was just curious about where your use of
terms originated and that now explained.

--
Ben.