Была ли когда-нибудь схема транслитерации APL-ASCII, которая достигла какого-либо существенного принятия? - PullRequest
Новая
       32

Была ли когда-нибудь схема транслитерации APL-ASCII, которая достигла какого-либо существенного принятия?

2 голосов
/ 06 марта 2020

Примерно в то время, когда я начал работать с APL в 1980-х годах, Джим Вейганг разработал схему транслитерации для записи кода APL в файл. Хотя сама схема была solid, вероятно, никогда не захочется программировать с ней. Одна схема транслитерации, которую я помню (только что нашел, APL Bang!) Выглядела так, как будто у нее может быть шанс. Обе записи Weigang и APL Bang! упоминаются здесь:

Подробнее о APL Bang! (который, похоже, прошел ревизию)

В последнее время появился язык ELI, имеющий собственную транслитерацию. Схема, только слегка похожая на APL Bang! Некоторая информация об ELI находится здесь:

Было несколько других схем транслитерации от APL * Plus / P C и другие, но это были вещи, которые играли второстепенную роль в APL, и с ними можно было программировать, но только в случае крайней необходимости. Я знаю о J, K и Q, но я бы не думал об этом как о «транслитерации», а о переработанных языках.

Ответы [ 2 ]

2 голосов
/ 11 марта 2020

Нет.

Я работаю с APL более 30 лет, и, хотя я знаю обо всех упомянутых, я видел лишь немногих избранных в реальной жизни, и тогда только как в крайнем случае из-за ограничений среды.

Хотя я, очевидно, не видел весь или весь код APL, я могу с уверенностью подтвердить, что ни одна такая схема транслитерации не достигла какого-либо существенного принятия.

Связанная разработка - это своего рода схема визуальной транскрипции, в которой один «dr aws» символ APL использует символы ASCII, а затем объединяет их. Например, -> составляет →, а xx составляет ×. Однако это чисто метод ввода, и соответствующий символ Unicode немедленно заменяет ASCII-арт. Он доступен как букмарклет .

1 голос
/ 14 марта 2020

Насколько мне известно, единственными системами APL, которые обеспечивали свою собственную встроенную транслитерацию, были STS C APL Plus / P C и системы APL для серии CD C 6600 мэйнфреймы, APLUM и, может быть, сам CD C. Транслитерация APL Plus / P C выглядела примерно так: 

A #is B / #iota #rho B

, в то время как APLUM выглядела примерно так: 

A $IS B / $IO $RO B

Я однажды попробовал транслитерацию STS C на P C без необходимого ПЗУ генератора символов APL. Перевод CD C, очевидно, был разработан для использования с терминалом Teletype модели 33. (Вы можете увидеть один из них в музее.) Эти функции были встроены в систему и, как правильно сказал Адам, использовались в качестве крайней меры из-за ограничений среды. Они, насколько мне известно, никогда широко не использовались .

Сказав это, для приложений, которые мы писали на мэйнфреймах (Sharp, STS C, VSAPL и др. c.) В в середине 1970-х было нормальным помещать подсказку в символьную подсказку, чтобы программист мог войти и выполнить какое-то обслуживание, например, удалить компонент файла, изменить переменную или скопировать что-либо. В одном случае это было даже возможно редактировать функционирует с помощью APL-альтернативы DEL-редактору, APL-версии EDLIN. Они были бы подкреплены нашей собственной функцией транслитерации для использования на терминалах не-APL, которая реализовала что-то вроде схемы APLUM (так как она была единственной в середине 1970-х годов) и была скопирована везде и всегда, когда это было необходимо. Несчастный в использовании, но спасатель, когда это необходимо. Подводя итог, можно сказать, что в первые дни транслитерация существовала, вам просто нужно было реализовать ее самостоятельно.

Некоторые приложения с разделением времени (например, 39 MAGI C от Sharp) были разработаны для использования на терминалах без APL. , При входе в службу с разделением времени система «знала», какой тип терминала вы используете, и будет соответствующим образом поддерживать его. Вы можете получить достаточно далеко без символов APL. Кроме того, многие из ранних терминалов, таких как IBM 2741 и различные принтеры с последовательным подключением AJ и Xerox Diablo, имели элементы сменного типа, так что наихудшей из возможных проблем была клавиатура без клавиатуры APL. Только с некоторыми более дешевыми терминалами ASCII проблема отсутствия поддержки APL была проблемой. Транслитерация ASCII часто не воспринималась как необходимость.

Полагаю, пользователи, которые действительно нуждались в транслитерации ASCII, перешли на J.

...