После ответа Аркадия Валентиновича я, кажется, понял, что имеется ввиду.
У нас есть значение какого-то сложного типа. Мы его конвертируем в объектное
выражение и в поле зрения оказывается значение с интерфейсом объектного
выражения. С ним можно выполнять операции в терминах Рефала и оно будет
преобразовываться в объектные значения лениво, по мере работы. Возможна для
этих значений и обратная конвертация, и она в определённых условиях будет
выполняться эффективно.
Проиллюстрирую, как понял мысль. Допустим, мы работаем с реляционной БД и
написали следующий код:
$ENTRY Go {
= <Modify <LoadDB 'sales.sqlite'>>
}
Modify {
e.Tables-B (CUSTOMER e.Cust-B (t.Name t.SurName 1234 t.Email) e.Cust-E)
e.Tables-E
= <SaveDB
e.Tables-B
(CUSTOMER e.Cust-B (t.Name t.SurName 1234 "[email protected]") e.Cust-E)
e.Tables-E
>
}
Здесь мы «прочитали» базу данных, заменили у клиента с ID 1234 почтовый адрес и
«сохранили». Но на самом деле полного чтения и сохранения не выполнялось,
функция SaveDB обнаружила изменённые данные и осуществила запрос UPDATE.
Значения переменных e.Tables-B, e.Tables-E, e.Cust-B и e.Cust-E — чёрные ящики.
Как и t.Name, t.SurName и t.Email до тех пор, пока мы не обратимся к их
содержимому (обращение форсирует запрос SELECT):
* форсирует SELECT:
Modify {
e.Tables-B (CUSTOMER e.Cust-B (t.Name t.SurName 1234 t.Email) e.Cust-E)
e.Tables-E
= <Prout t.Name t.SurName t.Emal>
}
* форсирует DELETE:
Modify {
e.Tables-B (CUSTOMER e.Cust-B (t.Name t.SurName 1234 t.Email) e.Cust-E)
e.Tables-E
= <SaveDB e.Tables-B (CUSTOMER e.Cust-B e.Cust-E) e.Tables-E>
}
* форсирует INSERT:
Modify {
e.Tables-B (CUSTOMER e.Customers) e.Tables-E
= <SaveDB
e.Tables-B
(CUSTOMER e.Customers ("Вася" "Пупкин" 2345 "[email protected]"))
e.Tables-E
>
}
* форсирует DROP TABLE
Modify {
e.Tables-B (CUSTOMER e.Customers) e.Tables-E
= <SaveDB e.Tables-B e.Tables-E>
}
Эффективная реализация здесь потребует JIT-компиляцию, как в Julia, либо, как
минимум, реализацию какой-то концепции (например, работы с БД) в виде
библиотеки классов с интерфейсом объектов Рефала (базовые операции
сопоставления и конкатенации).
С уважением,
Александр Коновалов
On нояб. 14 2024, at 3:13 дня, Arkady Klimov arkady.klimov_AT_gmail.com
<[email protected]> wrote:
> Идея про "линзы" мне кажется интересной. Я тоже всегда старался избежать
> изменений языка, а манипулировать реализацией.
> В частности это имеет отношение и к таблицам.
>
> К сожалению, у нас все существующие реализации рефала работают в своем
> одном-единственном представлении выражений: список двусвязный, массив, список
> с подвешиванием и т.п.
> Хотелось бы "обобщить" представление для выражений с тем, чтобы допускались
> одновременно различные представления, в том числе "скрытые",
> инкапсулированные, через типа объектный интерфейс.
> Тогда можно было бы таблицы представлять так, как это все делают в
> библиотеках, а использовать через "виртуальные" 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
> (http://a.v.konovalov87_AT_mail.ru) <[email protected] (mailto:[email protected])>:
> > Да, это синтаксический сахар к паре хранимых процедур. Точно также, как
> > свойство — синтаксический сахар к геттеру и сеттеру. И это тоже даёт
> > удобство и гибкость.
> >
> >
> > From: Sergei Skorobogatov s.yu.skorobogatov_AT_gmail.com
> > (http://s.yu.skorobogatov_AT_gmail.com) <[email protected]
> > (mailto:[email protected])>
> > Sent: Thursday, November 14, 2024 1:03 AM
> > To: [email protected] (mailto:[email protected])
> > Subject: Re: Синтаксис словарей в Рефале!
> >
> >
> >
> >
> > On Wed, Nov 13, 2024 at 7:31 PM Александр Коновалов
> > a.v.konovalov87_AT_mail.ru (http://a.v.konovalov87_AT_mail.ru)
> > <[email protected] (mailto:[email protected])> wrote:
> > > То, что Вы называете «линзы», другие называют парой из геттера и сеттера
> > > или акцессора и модификатора.
> > >
> >
> >
> >
> > Ага, а то, что в реляционных базах называют представлениями (views), другие
> > называют парой хранимых процедур: одна вытаскивает данные из нескольких
> > таблиц, а другая -- записывает данные в несколько таблиц, так? :-)
> >
> >
> >
> > На самом деле -- не так, потому что к представлениям можно обращаться из
> > SQL-запросов абсолютно так же, как к таблицам. И это даёт большое удобство
> > и гибкость.
> >
> >
> >
> >
> >
> >
>
>
>
