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
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.
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.
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?
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 andAFAIR, COBOL didn't have types, but you could define a variable LIKE
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 recordsOf course, in LISP there is only one structure, for data and programs
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 :
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!
Of course, in LISP there is only one structure, for data and programs
alike: the list!
AFAIR, COBOL didn't have types, but you could define a variable LIKE
another one.
However, Wikipedia says that the COBOL record structure inspiredOf course, in LISP there is only one structure, for data and programs
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.
alike: the list!
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.
Le 13/05/2023 à 18:53, Niklas Holsti a écrit :
AFAIR, COBOL didn't have types, but you could define a variable LIKEWhat 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.
another one.
Of course, in LISP there is only one structure, for data and programs
alike: the list!
Of course, in LISP there is only one structure, for data and programs alike: the
list!
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 andAFAIR, COBOL didn't have types, but you could define a variable LIKE
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.
another one.
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.
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?
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 ::=
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?
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).
Seems rather OT for c.l.a.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 399 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 64:57:32 |
| Calls: | 8,355 |
| Calls today: | 15 |
| Files: | 13,159 |
| Messages: | 5,893,946 |
| Posted today: | 1 |