Всем привет!
Давно не философствовали, надо разнообразить досуг

Есть тупль, ну например t1=(x,y). Есть ещё один t2=(y,x).
Они равны? нет, так как тупли равны когда равны все элементы на одинаковых позициях.
Теперь "для удобства" (на самом деле когда 2 элемента это не сильно надо, но кортеж может быть из большего кол-ва элементов)
вводим возможность именования позиций (например a b для нашего случая). То есть элемент теперь можно получать
не только по индексу позиции, но и по идентификатору, например tuple.a
Но этож уже по сути рекорд! а рекорды равны, когда равны все соответствующие поля (для упрощения будем считать что состав идентификаторов полей у них совпадает, как в нашем примере).
Допустим у нас есть ещё тупль (рекорд?) t3=(b:y, a:x)
Если сравнивать по правилам туплей то t1 и t3 — не равны.
А если по правилам рекордов, то t1 и t3 равны (у обоих a=x, b=y).

Дак становится ли тупль рекордом когда его мемберы сделали инменованными?
Вроде как нет, ведь добавив "для удобства" именования позициям мы ведь вроде как не изменили структуру данных.
Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?

Также вспомним select из sql, он что возвращает? кортеж с возможностью доступа по именам или рекорд?...
как верно идеалогически?

Кортеж это упорядоченное конечное множество элементов. Запись это именованное неупорядоченное конечное множество элементов.

Если ты присваиваешь элементам кортежа наименования, по сути ты вводишь псевдонимы. Это ничего не меняет в кортеже, первенствующая сущность это по прежнему порядок. В том же SQL ты можешь делать union и он оперирует исключительно позициями столбцов, а не их именами.

В случае с записью порядка нет априори. Имя это единственная возможность обращаться к элементу.

Если говорить об операции сравнения, я бы предложил выкидывать исключение, если сравниваются два кортежа с именованными полями, названия которых не совпадают (конечно должна быть возможность переименовать или просто убрать именования с полей в рамках системы типов, если программист всё же хочет их сравнить). Сравнение же идёт по индексу.

Здравствуйте, vsb, Вы писали:

vsb>В случае с записью порядка нет априори. Имя это единственная возможность обращаться к элементу.

Почему же? Есть рефлексия. Можно точно так же перечислить поля записи, не зная их имен.

Здравствуйте, Ops, Вы писали:

vsb>>В случае с записью порядка нет априори. Имя это единственная возможность обращаться к элементу.

Ops>Почему же? Есть рефлексия. Можно точно так же перечислить поля записи, не зная их имен.

Это уже не абстракция, а конкретный язык программирования. А я про абстрактное понятие говорю. В С рефлексии, например, нет. Кроме того если ты переупорядочишь поля в объявлении записи, код (написанный без хаков) будет работать как работал.

Здравствуйте, vsb, Вы писали:

vsb>Это уже не абстракция, а конкретный язык программирования. А я про абстрактное понятие говорю. В С рефлексии, например, нет.

Так в С и туплов нет. А если написать на самом языке, как, например, делают в плюсах, то с тем же успехом можно и структуру на стероидах сделать, с рефлексией, и это тоже не редкость, хоть и выглядит обычно не слишком красиво.

vsb>Кроме того если ты переупорядочишь поля в объявлении записи, код (написанный без хаков) будет работать как работал.

Да, есть такое. В чем разница с туплом с именованными элементами? Он тоже по именам будет продолжать работать, а по порядку точно так же сломается.

Нельзя, наверное, в отрыве от языка рассматривать. Абстракция-то из практических нужд родилась, а не ради богословских споров.

Здравствуйте, Ops, Вы писали:

vsb>>Это уже не абстракция, а конкретный язык программирования. А я про абстрактное понятие говорю. В С рефлексии, например, нет.

Ops>Так в С и туплов нет.

Ну в данном случае речь о записях.

vsb>>Кроме того если ты переупорядочишь поля в объявлении записи, код (написанный без хаков) будет работать как работал.

Ops>Да, есть такое. В чем разница с туплом с именованными элементами?

В том, что с туплом ты пишешь код вида `let (a, b) = tuple`, где деструктуризация идёт по позициям. Именованные элементы там или нет, значения не имеет, пока речь о кортеже. И если ты поменяешь порядок полей, то семантика кода изменится там, где не используются именованные элементы.

Если ты работаешь с записью через рефлексию и твой код зависит от порядка полей в записи, значит это уже не запись, а такой же кортеж.

Ops>Нельзя, наверное, в отрыве от языка рассматривать. Абстракция-то из практических нужд родилась, а не ради богословских споров.

Ну суть в том, что у разных языков программирования имеются общие черты. Поэтому и выделяют какие-то сущности на более абстрактном уровне. Массивы, записи есть практически в каждом ЯВУ. Кортежи, вот, далеко не в каждом. Понятно, что если речь идёт о C, то порядок полей в исполняемом файле будет таким же, как объявлен в struct и если знать логику выравнивания и размеры типов, можно даже к этим полям достучаться по индексу. Но это уже особенности реализации этой сущности в языке С. В Java порядок полей спецификацией не гарантируется, например.

Здравствуйте, vsb, Вы писали:

vsb>Ну в данном случае речь о записях.

И зачем их рассматривать в языке, в котором сравнить сравнить не с чем? Ну, не теряя контекст темы?

vsb>Если ты работаешь с записью через рефлексию и твой код зависит от порядка полей в записи, значит это уже не запись, а такой же кортеж.

Так о том и речь, что разницы иногда нет.

vsb>Ну суть в том, что у разных языков программирования имеются общие черты. Поэтому и выделяют какие-то сущности на более абстрактном уровне. Массивы, записи есть практически в каждом ЯВУ. Кортежи, вот, далеко не в каждом. Понятно, что если речь идёт о C, то порядок полей в исполняемом файле будет таким же, как объявлен в struct и если знать логику выравнивания и размеры типов, можно даже к этим полям достучаться по индексу. Но это уже особенности реализации этой сущности в языке С. В Java порядок полей спецификацией не гарантируется, например.

Все верно. Только исходя из общей базы нельзя дать ответ на вопрос темы, поскольку за это отвечают именно отличающиеся от языка к языку особенности, а не она. Где-то структуры с туплами могут быть взаимозаменяемыми, где-то нет.

Здравствуйте, MadHuman, Вы писали:

MH>Всем привет!
MH>Давно не философствовали, надо разнообразить досуг

По факту использования кортежей(тупл звучит совсем "тупо") в C#
пришел к выводу, что кортежи вредны, т.к. ухудшают читаемость кода.
Органичить применение кортежей локальными функциями, если нужно вернуть более одного значения в одном месте, которое будет использовано только в контексте метода.
В методах обязательно параметры и возврат описывать как класс или структуру.

Здравствуйте, vsb, Вы писали:

vsb>Кортеж это упорядоченное конечное множество элементов. Запись это именованное неупорядоченное конечное множество элементов.
да

vsb>Если ты присваиваешь элементам кортежа наименования, по сути ты вводишь псевдонимы. Это ничего не меняет в кортеже, первенствующая сущность это по прежнему порядок.
на первый взгляд да. но собственно что мешает теперь этой структуре быть записью? основное свойство записи есть — все элементы именованы.

vsb>В том же SQL ты можешь делать union и он оперирует исключительно позициями столбцов, а не их именами.
да, с точки зрения операции union, результаты селектов интерпретируются как кортежи.
хотя в теориях баз данных (реляционной алгебре), вроде как раз как кортежы с именованными элементами, то есть — записи.
и это странно.

vsb>Если говорить об операции сравнения, я бы предложил выкидывать исключение, если сравниваются два кортежа с именованными полями, названия которых не совпадают (конечно должна быть возможность переименовать или просто убрать именования с полей в рамках системы типов, если программист всё же хочет их сравнить). Сравнение же идёт по индексу.
сомнительное предложение. ведь если это было два кортежа, по после добавления наименования элементам по вашему утверждению — "Это ничего не меняет в кортеже, первенствующая сущность это по прежнему порядок".
раз ничего не меняет, то плохо что возможность их сравнивать пропадает.

Здравствуйте, MadHuman, Вы писали:

MH>Дак становится ли тупль рекордом когда его мемберы сделали инменованными?
1) IMHO, этот спор, как и любой спор о терминах бессмысленный. Лучше не спорить , а выбрать как правильно говорить, так, что бы все одинаково понимали, что имеется в виду.
2) С колокольни моего идиалекта, кортеж -- это объединение разнотипных данных, созданное по случаю. БЕЗ ПРЕДВАРИТЕЛЬНОГО ОБЪЯВЛЕНИЯ. В этом смысле какая-нибудь std::pair ближе к кортежу, чем к структуре, хотя в языке оформлена, как структура, а не кортеж. Ну да это особенность системы типов С++ просто. Там и сам по себе tuple оформляют как экземпляр специализации шаблонного структуры/класса.
В этом смысле не важно, добавляем мы к позициям кортежа метки или нет. Всё равно, пока мы его определяем по случаю, это не структура. У структуры, с моей т. з, должно быть определение.
3) Но тут можно рассмотреть ещё один аспект. В целом для каждого члена, что записи, что кортежа, есть два параметра -- метка, и тип. В случае кортежа, метка -- это порядковый номер, в случае записи -- имя. При этом в случае кортежа мы тип записи с определённой меткой задаём в определении, а в случае кортежа -- по месту создания.
При этом можно рассмотреть ещё и другие сочетания.
3а) Две системы меток, по номерам и по именам. Мало того, можно где-то описывать шаблоны таких кортежей.
Например, мы описываем в типе результата функции, что она вернёт вес, длину и индекс красивости.
Потом в функции в произвольном порядке собираем кортеж из этих параметров, с их метками, а на выходе имеем кортеж, где метки ещё и упорядочены как надо.
Что-то тдалённо похожее есть в python, например (namedtuple называется, если я верно помню)
3б) Запись, у которой предварительно объявлены имена полей, но не типы. Например, шаблонная структура в С++. Скажем std::pair
3в) кортеж, в котором заранее заданы типы 1-го, 2-го и т. д. элементов. И строить можно его по перечислению элементов тех же типов в произвольном порядке. Пример -- множественное наследование в С++
3г) Запись, лишённая предварительного объявления и заданного порядка итерации. То есть отображение имён на значения, созданное по случаю. С неизвестными заранее именами и типами значений. Пример -- хэш из PERL (он же словарь из C#, python, Java и т. д...)
Ну и т. д.

Лично меня это подвигает к мысли, что нужно иметь какую-то табличку признаков.
Ну типа

1.1 Нужно объявлять предварительно набор имён полей
1.2 Можно объявлять предварительно набор имён полей
1.3 Можно задавать набор имён полей по случаю, в момент создания

2.1 Нужно объявлять предварительно итератор полей
2.2 Можно объявлять предварительно итератор полей
2.3 Можно задавать итератор полей по случаю, в момент создания

3.1 Нужно объявлять предварительно типы полей
3.2 Можно объявлять предварительно типы полей
3.3 Можно задавать типы полей по случаю, в момент создания

И просто договориться, что кортежем мы, называем такую структуру данных, где 2.3, 3.3 -- истина, а 3.2, 2.2, 1.2, 1.3 -- могут быть, а могут и не быть.
А можно договориться построже, что кортеж, это только если 2.3 и 3.3 а больше ничего. Правда, тогда namedtuple придётся не считать tuple, хотя они и связаны отношением наследования...

Тоже самое и с записью. Классическая запись (как в Pascal, например) -- это 1.1 и 3.1 -- истина, а остальное ложь. Но можно расширить как-то ещё. Например, разрешить иметь объявляемый по случаю порядок полей. Или не по случаю, а предварительно (это соответствует наличию в языке рефлексии) и т. д.

MH>Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?
Потому, что часто будет не понятно, что имеется в виду.

MH>Также вспомним select из sql, он что возвращает? кортеж с возможностью доступа по именам или рекорд?...
MH>как верно идеалогически?
На мой взгляд вариантов больше 2-х, но если надо склониться к какому-то из двух, то скорее кортеж...

Здравствуйте, MadHuman, Вы писали:

MH>Дак становится ли тупль рекордом когда его мемберы сделали инменованными?
MH>Вроде как нет, ведь добавив "для удобства" именования позициям мы ведь вроде как не изменили структуру данных.
MH>Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?

Ответ на вопрос лежит в словосочетании "мемберы сделали именованными", потому что оно неоднозначно.

Могут быть такие варианты трактовки:

1) Доступ к элементам сущности возможен по имени поля ("a = entity.FieldName;"). Результат: получившаяся сущность с точки зрения использования полностью эквивалентна рекорду (с той разницей, что для нашей сущности возможно существование операции упаковки — конструктора, принимающего упорядоченный список аргументов).

2) Доступ к элементам сущности по имени поля НЕВОЗМОЖЕН! Доступ возможен только через распаковку ("(a, b) = entity;"), а имена полей служат "хинтом" к содержимому, лежащему в сущности. Результат: это по-прежнему тупл, только более понятный.

Здравствуйте, AlexRK, Вы писали:


ARK>Ответ на вопрос лежит в словосочетании "мемберы сделали именованными", потому что оно неоднозначно.

ARK>Могут быть такие варианты трактовки:
нет, тут дело не в трактовке действия. действие как раз однозначное и понятное — элементам кортежа, дали имена полей "хинты". для удобства.
вы трактуете по сути — как оформить и интерпретировать результат такого действия. собственно да, что в результате получим и почему — в этом и нет однозначности.

ARK>1) Доступ к элементам сущности возможен по имени поля ("a = entity.FieldName;"). Результат: получившаяся сущность с точки зрения использования полностью эквивалентна рекорду (с той разницей, что для нашей сущности возможно существование операции упаковки — конструктора, принимающего упорядоченный список аргументов).
это уже не элементам тупля дали имена, это из тупля создали рекорд.
или тоже самое — дали имена, но возможность доступа по позиции убрали.
в таком случае конечно, всё однозначно.


ARK>2) Доступ к элементам сущности по имени поля НЕВОЗМОЖЕН! Доступ возможен только через распаковку ("(a, b) = entity;"), а имена полей служат "хинтом" к содержимому, лежащему в сущности. Результат: это по-прежнему тупл, только более понятный.
почему не возможен? это уже детали реализации, представьте что в этой структуре данных для этого реализован интерфейс типа IRecord c GetFieldValue(string name), или прям явный с пропертями, соотвествующими именам полей (типа как namedtuple в питоне).
но тут проблема — этот тупль с косметическим улучшением (именами полей для содержимого) начинает обладать всем признаками рекорда.
и нет причин не считать его таковым.
но если считать рекордом, то возникает противоречие при сравнении двух разных таких структур.


подумайте ещё над тем что возвращает select в sql. не столько с позиции как сейчас сложились в популярных реализациях, а с позиции — а как правильно.
представьте что строку из результата надо сохранить в переменную.
какого типа эта переменная? кортеж? или рекорд? как сравнивать два таких значения ?

let a=select 1 as x, 2 as y
let b=select 2 as y, 1 as x

a=b?
можно ли делать a[0]?
а a.x?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, MadHuman, Вы писали:

MH>>Дак становится ли тупль рекордом когда его мемберы сделали инменованными?
E>1) IMHO, этот спор, как и любой спор о терминах бессмысленный. Лучше не спорить , а выбрать как правильно говорить, так, что бы все одинаково понимали, что имеется в виду.
да нет) термины тупль (кортеж) и рекорд вполне себе определены и с их определением нет неоднозначностей. процитирую vsb:
"Кортеж это упорядоченное конечное множество элементов. Запись это именованное неупорядоченное конечное множество элементов"


E>2) С колокольни моего идиалекта, кортеж -- это объединение разнотипных данных, созданное по случаю. БЕЗ ПРЕДВАРИТЕЛЬНОГО ОБЪЯВЛЕНИЯ.
это не обязательно, можно и с предварительным объявление, в F# мы можем объявить:
type Poin = int * int // это уже предварительное объявление. по сути Poin — это алиас к типу int * int.
и далее тип Poin везде обладает всем свойствами tuple. и никаких неоднозначностей это не вызывает.
на мой imho требование "БЕЗ ПРЕДВАРИТЕЛЬНОГО ОБЪЯВЛЕНИЯ" чрезмерно.

E> В этом смысле какая-нибудь std::pair ближе к кортежу, чем к структуре, хотя в языке оформлена, как структура, а не кортеж. Ну да это особенность системы типов С++ просто. Там и сам по себе tuple оформляют как экземпляр специализации шаблонного структуры/класса.
ну это уже детали реализации.

E>В этом смысле не важно, добавляем мы к позициям кортежа метки или нет. Всё равно, пока мы его определяем по случаю, это не структура. У структуры, с моей т. з, должно быть определение.
сейчас в языках уже добавляют возможности определять по месту и анонимные рекорды. и в туплях давать имена позициям и далее по именам обращаться.
всё таки признак — где определяем (в момент создания, то есть без предварительного определения, либо с предварительным определением) — не определяющий для структурных свойств структуры данных.

E>... Лично меня это подвигает к мысли, что нужно иметь какую-то табличку признаков.
E>Ну типа
E>1.1 Нужно объявлять предварительно набор имён полей
это да, то есть может быть тем исходным действием, ведущем к противоречию (элементам тупля дали имена).
E>1.2 Можно объявлять предварительно набор имён полей
если этого не сделали — не сделали обсуждаемое действий, у нас просто тупль, и исходного вопроса и противоречия нет.
E>1.3 Можно задавать набор имён полей по случаю, в момент создания
тоже можно, просто момент выполнения действия — в момент создания (не в момент декларации)
на мой imho (здесь и далее), это всё вариации "в какой момент" применять действие и не отвечает на вопрос — как интерпретировать его результат (тупль с именами).

E>2.1 Нужно объявлять предварительно итератор полей
E>2.2 Можно объявлять предварительно итератор полей
E>2.3 Можно задавать итератор полей по случаю, в момент создания
это про возможности рефлексии структуры данных. также непересекается с тем как интерпретировать тупль с именами.

E>3.1 Нужно объявлять предварительно типы полей
E>3.2 Можно объявлять предварительно типы полей
E>3.3 Можно задавать типы полей по случаю, в момент создания
и это тоже не про интерпретацию тупля с именами.

Здравствуйте, MadHuman, Вы писали:

ARK>>2) Доступ к элементам сущности по имени поля НЕВОЗМОЖЕН! Доступ возможен только через распаковку ("(a, b) = entity;"), а имена полей служат "хинтом" к содержимому, лежащему в сущности. Результат: это по-прежнему тупл, только более понятный.
MH>почему не возможен? это уже детали реализации, представьте что в этой структуре данных для этого реализован интерфейс типа IRecord c GetFieldValue(string name), или прям явный с пропертями, соотвествующими именам полей (типа как namedtuple в питоне).

Нет, это не просто деталь реализации. Метод GetFieldValue написать нельзя, т.к. имена полей недоступны из кода. Мы можем только посмотреть на них глазами, точно так же, как в С — на имена входных параметров функции, находясь извне функции. Имена полей — именно что просто хинт и ничего больше. Если их можно каким-то образом использовать из кода, то это уже вариант 1 ("Доступ к элементам сущности возможен по имени поля").

MH>но тут проблема — этот тупль с косметическим улучшением (именами полей для содержимого) начинает обладать всем признаками рекорда.

Только в варианте 1.

MH>подумайте ещё над тем что возвращает select в sql. не столько с позиции как сейчас сложились в популярных реализациях, а с позиции — а как правильно.

Как правильно, это сложный вопрос. У меня недостаточно квалификации для таких суждений.

Фактически сейчас возвращается рекорд.

MH>представьте что строку из результата надо сохранить в переменную.
MH>какого типа эта переменная? кортеж? или рекорд? как сравнивать два таких значения ?

Рекорд. Сравнивать по правилам рекорда.

MH>let a=select 1 as x, 2 as y
MH>let b=select 2 as y, 1 as x

MH>a=b?

Да.

MH>можно ли делать a[0]?

Нельзя.

MH>а a.x?

Можно.


UPD.
Изначально в любом случае сущность одна — либо с позиционным доступом, либо с именованным. А уж потом, на основе базового доступа, можно сверху дополнительно прикрутить другой доступ — но он всегда будет в "подчиненном" положении и на операцию сравнения влиять не будет.

Как прикрутить? На основе какого-то правила, общего для всех сущностей в интересующем нас множестве. Да, обязательно общего для всех сущностей в интересующем нас множестве, иначе выйдет нелепость! Множеством может быть в общем случае что угодно. Например, для SQL это "рекордсет" (набор связанных рекордов), который возвращается каждым SELECT-запросом.

Как из позиционного доступа сделать именованный? Можно, например, добавить префикс "Field" к индексу и получить имена полей а-ля "Field1", "Field2", etc.
Как из именованного доступа сделать позиционный? Можно использовать словарь, ставящий в соответствие некоторой строке некоторое число ("{ "MyField1" => 1, "OtherField" => 2 }").


Можно, в принципе, сделать и сущность со "смешанным" доступом. Но при этом должно выполняться одно из трех условий.

Рассматриваем тот же пример:
let a=select 1 as x, 2 as y
let b=select 2 as y, 1 as x

1) Всегда явно задаются оба параметра (имя и позиция). С этом случае будет a!=b, т.к. имена совпадают, а позиция — нет.

2) Опираться на некоторое, общее для всех, правило преобразования доступов друг в друга. В зависимости от этих правил, может быть либо a!=b, либо a=b, но b[0]=1! (хе-хе )

3) Нести в себе (в своем типе) правило преобразования доступов друг в друга. Почти как вариант 2, но надо явно указывать тип:
let a=MyTupleRecordRule(select 1 as x, 2 as y)
let b=MyTupleRecordRule(select 2 as y, 1 as x)
Будет ли в этом случае a=b — неизвестно, зависит от того, что в MyTupleRecordRule.

В общем, смешанный доступ — это хрень, усложняющая все, но не приносящая особой пользы.

Здравствуйте, MadHuman, Вы писали:
MH>let a=select 1 as x, 2 as y
MH>let b=select 2 as y, 1 as x

MH>a=b?
MH>можно ли делать a[0]?
MH>а a.x?
Я бы делал примерно так:
1. Любой рекорд, очевидно, можно считать кортежем — у него есть номера. В воображаемом синтаксисе мы могли бы обращаться к элементам кортежа как a.1, a.2, и так далее. Рекорд задаёт ещё и имена.
2. Приведение кортежа к рекорду — только явное.
3. Сравнение двух рекордов идёт по именам и типам, сравнение кортежей — по позициям.
4. Сравнение рекорда с кортежем идёт по позициям, в силу п.1 и п.3.
5. Детали зависят от вкуса дизайнеров языка. Например, можно принудительно применять runtime type при выполнении сравнений, а можно — формальный тип выражения.

Здравствуйте, MadHuman, Вы писали:

MH>Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?
Собственно вопрос терминологии. Те туплы что ты имеешь в виду называют Structural Tuple, а records — Nominal Tuple.

Здравствуйте, MadHuman, Вы писали:

MH>Есть тупль, ну например t1=(x,y). Есть ещё один t2=(y,x).
MH>Они равны? нет, так как тупли равны когда равны все элементы на одинаковых позициях.

А что сравниваем-то?
Например, в первом тупле (кг, м/с) во втором (Гц, Вт), что тогда?
А низлежащие типы данных совпадают...

В общем, при любом сравнении важна семантика, т.е. даже не всегда важно представление данных.
Например, можно сравнивать float с double, с int, с long и т.д. с некоторой заданной точностью.


MH>вводим возможность именования позиций (например a b для нашего случая). То есть элемент теперь можно получать
MH>не только по индексу позиции, но и по идентификатору, например tuple.a

1. tuple.a — оксюморон.
2. Именование тоже не принципиально, бо любое именование — лишь некий алиас числа сугубо для глупца-человека.

Взять ту же БД, в одной таблице {Id, SubId, ..}, в другой { ParentSubId, ParentId, .. }.
Не смотря на разные названия и разное положение полей в таблице, тут должно быть понятно, что с чем можно сравнивать при построении join-запросов.
Т.е., опять важна лишь семантика, а хорошо подобранные идентификаторы помогут человеку сориентироваться в ней.


MH>Дак становится ли тупль рекордом когда его мемберы сделали инменованными?

В математике упорядоченный набор данных называют кортежом (tuple), в программировании записью (record).
Де-факто это одно и то же.
Исторически в математике принято ссылаться на элементы кортежа по индексу, а в программировании принято ссылаться на элементы записи по символьному идентификатору.

"Раскручиваем" нынешнее положение вещей:
* Идентификатор переменной в ЯП — это отсылка к некоему адресу (если это идентификатор поля структуры, то адрес от начала структуры).
* Адрес — это индекс первой ячейки памяти значения.
Круг замкнулся. ))
(почти)


MH>Вроде как нет, ведь добавив "для удобства" именования позициям мы ведь вроде как не изменили структуру данных.

Так и есть.


MH>Но опять же, а почему собственно нет? ведь все признаки (структура) рекорда налицо... почему это не рекорд?

ИМХО, это накопленная ошибка процесса развития практик в IT. ))

Изначально в некоторых языках ФП было замечено, что порой лаконичности (т.е. удобства) добавляют ср-ва позиционного оперирования полями записи, а в этих операциях важен индекс поля (как в математике), поэтому и назвали структуру, над которой можно производить позиционные операции, tuple.

Забавно, однако, что для указания смены позиций (индексов) в тупле всё-равно используют идентификаторы, а не числа.
Например, swap значений переменных в C#:

// C#
int a = 1, b = 2;
(a, b) = (b, a);

И обратно — позиционное оперирование именованными полями (инициализация типов-агрегатов в C/C++ и обратная их декомпозиция):

struct {int x, y;} s = {1, 2};
auto [a, b] = s;

Т.е., вводить новомодные tuple в языки программирования было не обязательно, достаточно было дать операции позиционного манипулирования над структурами-агрегатами.
Сейчас-то это уже понятно...
Но туплы уже "протекли" в программистский обиход, лишний раз напоминая людям о их (людях) несовершенстве. ))


MH>Также вспомним select из sql, он что возвращает? кортеж с возможностью доступа по именам или рекорд?...

С т.з. зрения программиста — запись.
С т.з. движка СУБД — кортеж, бо по индексу адресация более эффективная.


MH>как верно идеалогически?

А как правильней: "древесина" или "материал из дерева"? ))