Идея про "линзы" мне кажется интересной. Я тоже всегда старался избежать
изменений языка, а манипулировать реализацией.
В частности это имеет отношение и к таблицам.
К сожалению, у нас все существующие реализации рефала работают в своем
одном-единственном представлении выражений: список двусвязный, массив,
список с подвешиванием и т.п.
Хотелось бы "обобщить" представление для выражений с тем, чтобы допускались
одновременно различные представления, в том числе "скрытые",
инкапсулированные, через типа объектный интерфейс.
Тогда можно было бы таблицы представлять так, как это все делают в
библиотеках, а использовать через "виртуальные" Get и Set.
Скажем, в рефале-6 есть разного вида контейнеры (списки, строки, вектора, и
даже битовые строки=числа), но все они концептуально хранят выражение. И
его можно достать через GETV и положить через SETV.
Да, сейчас это выполняется буквально: содержимое копируется в списковый
формат и наоборот. И это, конечно, ограничивает свободу рук.
А что, если бы это выполнялось "виртуально", а все операции отождествления
и последующие SET... исполнялись "внутри" объектов, имеющих свое особое
представление.
Рассмотрим, например, таблицу sT. Условимся, что ее содержимое - это список
термов-пар вида (tK eV), где tK - ключ, eV - значение.
Тогда можно было бы писать:
... <GETV sT> : eL (tK eV) eR , ... = <SETV sT eL (t.K1 e.V1) eL>
но в реализации иметь внутри доступ по ключу (во внутреннем представлении!)
с последующим его удалением и добавлением новой пары (а если t.K1 == tK, то
просто заменой значения).
Конечно, при этом реализация должна быть уверена, что где-то между не было
другого доступа к sT (иначе сваливаться в тупое копирование).
Основная теоретическая проблема - как компилятору понять, когда какой
доступ нужен.
Если все решать динамически, нужны будут или варианты кода или достаточно
высокоуровневый язык "сборки", который от представления не зависит (что
наверно будет неэффективно).
Мне кажется, может помочь опыт языка Julia, в котором вариант эффективного
кода генерируется in run-time с учетом типов поданных аргументов.
Этот подход, если его скрестить бесшовно с языком реализации, мог бы дать
возможность в рефале его средствами работать с итераторами, разного рода
контейнерами, таблицами, словарями из готовых библиотек - НЕПОСРЕДСТВЕННО.
В рефале-6 в зачаточной форме эта "виртуальность" реализуется при доступе к
выражениям внутри термов.
Например, пусть мы выделили где-то кусок в виде переменной eX и далее
пишем: ... , eX : e1 tA e2 , eX : e3 tB e4 ... , то есть хотим проверить
наличие внутри e1 одновременно термов tA и tB (в любом порядке).
Все это делается без дополнительных копирований eX. Здесь важно, что перед
двоеточиями стоит чисто eX без добавок, иначе будут и копирование и
конкатенации.
Имхо. такое развитие рефала вполне соответствовало бы современному уровню
науки
С уважением,
Аркадий
чт, 14 нояб. 2024 г. в 08:14, Александр Коновалов a.v.konovalov87_AT_mail.ru
<[email protected]>:
> Да, это синтаксический сахар к паре хранимых процедур. Точно также, как
> свойство — синтаксический сахар к геттеру и сеттеру. И это тоже даёт
> удобство и гибкость.
>
>
>
> *From:* Sergei Skorobogatov s.yu.skorobogatov_AT_gmail.com <[email protected]>
>
> *Sent:* Thursday, November 14, 2024 1:03 AM
> *To:* [email protected]
> *Subject:* Re: Синтаксис словарей в Рефале!
>
>
>
> On Wed, Nov 13, 2024 at 7:31 PM Александр Коновалов
> a.v.konovalov87_AT_mail.ru <[email protected]> wrote:
>
> То, что Вы называете «линзы», другие называют парой из геттера и сеттера
> или акцессора и модификатора.
>
>
>
> Ага, а то, что в реляционных базах называют *представлениями* (views),
> другие называют парой хранимых процедур: одна вытаскивает данные из
> нескольких таблиц, а другая -- записывает данные в несколько таблиц, так?
> :-)
>
>
>
> На самом деле -- не так, потому что к представлениям можно обращаться из
> SQL-запросов абсолютно так же, как к таблицам. И это даёт большое удобство
> и гибкость.
>
