Файлы компонентов APL, собственные файлы и базы данных

Я новичок в APL и начинаю работать над кодовой базой APL, которая активно использует файлы компонентов APL (например, ⎕FSTIE, ⎕FREAD, ⎕FAPPEND). Меня также попросили исследовать передачу содержимого этих файлов компонентов в базу данных SQL, смысл которой состоял бы в том, чтобы сделать данные доступными для других приложений.

Некоторые из файловых компонентов содержат текст, который на первый взгляд выглядит так, как будто он будет работать нормально, если будет храниться в собственном файле, но основная часть файлов компонентов в основном содержит «неправильные» числовые матрицы, которые навскидку кажутся мне чем-то, что в конечном итоге будет реализованы как одна таблица DB2 на компонент. До сих пор самым большим было что-то вроде 500 строк x 20 столбцов. Я еще не видел (сознательно) каких-либо вложенных массивов, хотя я только слегка поцарапал поверхность. Пока только символьный текст и числовые векторы и матрицы.

Будет ли перенос содержимого этих файлов компонентов в Native Files разумным вариантом? Зачем вообще использовать файлы компонентов APL?

Используемая система APL — это Dyalog APL под Windows 7. Она существует уже некоторое время, и никто не знает, как долго.


apl dyalog
person Apollo 42    schedule 18.10.2017    source источник
comment
Было бы полезно знать, какие типы компонентов существуют в файлах. Файлы компонентов APL могут хранить вещи, которые не имеют стандартизированного текстового представления.   -  person Adám    schedule 18.10.2017

Ответы (2)


arrow_upward
1
arrow_downward

Преимущество использования файлов компонентов заключается в том, что вы можете читать/записывать любой APL-массив (сколь угодно сложный и большой) с помощью одной встроенной операции в/из файла, в то время как вам может потребоваться написать свои собственные специальные функции, если вы хотите сделайте это для большого сложного массива в формате .TXT или .XML. (К счастью, ⎕CSV и ⎕XML Dyalog сделают это за вас, но с точки зрения производительности файлы компонентов почти наверняка выиграют.)

person MBaas    schedule 18.10.2017
comment
На самом деле, ⎕CSV и ⎕XML не могут просто хранить любой произвольный массив APL в виде текстового файла. Действительно, не существует согласованного текстового представления произвольных массивов APL. - person Adám; 18.10.2017
comment
Спасибо за Ваш ответ. Цель состоит в том, чтобы совместно использовать данные между приложениями (не APL), приложениями, которые иначе не могут читать файлы компонентов. - person Apollo 42; 19.10.2017

arrow_upward
1
arrow_downward

Первая файловая система была разработана совместно I.P.Sharp Associates и STSC, двумя ведущими компаниями APL, занимающимися разделением времени, в конце 1960-х годов. Файловая система и новые системные функции, такие как []FMT, форматирование отчетов, были частью усилий по повышению коммерческой жизнеспособности APL\360. Предложение IBM того времени, APL.SV, представляло TSIO как аналог Native Files. Существовали вторичные файловые системы для APL.SV, а также для будущих интерпретаторов IBM, таких как VSAPL и APL2.

Зачем вообще использовать файлы компонентов APL?

В то время при использовании разделения времени Sharp или STSC это было единственное доступное средство. Кроме того, файловая система очень упростила разработку. Возможно, это был лучший способ сохранить данные APL, когда альтернативой было использование собственных файлов. Если ваша система изначально работала с разделением времени или использовала некоторые из ранних интерпретаторов STSC (Manugistics), она, вероятно, с самого начала использовала файлы компонентов. Доступ к DB2 из APL, сначала в виде AP127 для мейнфреймов APL2 и Sharp APL, появился несколько позже, примерно в середине 1980-х.

Естественно, файловые системы компонентов разных производителей, как и рабочие пространства, были несовместимы.

Будет ли перенос содержимого этих файлов компонентов в Native Files разумным вариантом?

Это зависит от содержимого. Звучит так, как будто в этих числовых компонентах может быть собственная база данных. Это открывает гораздо больший вопрос миграции данных.

person Lobachevsky    schedule 19.10.2017