LINUX.ORG.RU

Lisp: Где применимы cons?

 cons,


1

6

Для начала небольшой «бенчмарк», С без всех оптимизаций в 7406000 раз быстрее.

(defun main ()
  (declare (optimize (speed 3)))
  (let ((n 99999) (l '()) (sum 0))
    (loop for i from 0 to n
	  do (setq l (append l (list i))))
    (setq sum 0)
    (loop for i from 0 to n
	  do (setq sum (+ sum (nth i l))))
    (format t "~d~%" sum)))
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
	long n = 99999, *l = NULL, count = 0, sum = 0;
	for (long i = 0; i <= n; i++) {
		l = realloc(l, (count + 1) * sizeof(long)); 
		l[count++] = i;
	}
	for (long i = n; i >= 0; i--) sum += l[i];
	printf("%ld\n", sum);
}

Для чего же нужны cons? В качестве универсального строительного блока, я считаю это одна из самых худших структур. Все ее преимущества заканчиваются на быстром добавлении в начало. Добавление в конец уже нежелательно, разрез в произвольном месте тоже, так как нету даже быстрого доступа к случайному элементу. Она медленная и неудобная, можно придумать кучу более быстрых и удобных структур. Даже JS на световые годы опережает Lisp со своим JSON, и его частое использование лишь подтверждает его удобство.

Так почему же cons из языка-ассемблера IPL 1956 года считается важным? Да, это неплохая структура для AST, если ваша машина имеет 16 кб памяти, но она распространилась по языку слишком широко.

★★★★★

Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от anonymous

conscell был бы в шоке от таких вопросов, ога :))

что такое cons? и какие тут cells? :)))

и как ими эффективно пользоваться через rplca/rplcd/nconc =set-car!/set-cdr! в XLISP чтобы лишний раз не cons-ился и GC не запускался.

anonymous
()
Ответ на: комментарий от monk

Форт читать можно только снизу вверх.

Форт точно также можно читать сверху вниз и при качественном именовании слов даже проще чем lisp. А дальше ты начинаешь углубляться в эти слова и смотреть как именно это реализуется. И проектировать форт программу можно и наверное нужно сверху вниз.

BRE ★★
()
Последнее исправление: BRE (всего исправлений: 2)
Ответ на: комментарий от BRE

при качественном именовании слов даже проще чем lisp

Но как? В лиспе скобки позволяют указать, что к чему относится. В форте любое слово не из стандартной библиотеки как-то меняет стек и уже непонятно, к каким элементам стека относится следующее.

Я уж не говорю про слова в форте, определяющие чтение следующих слов.

monk ★★★★★
()
Ответ на: комментарий от monk

На верхнем уровне считается хорошим подходом иметь декларативный стиль, ну ты наверное видел пример со стиральной машиной:

: WASHER  WASH    SPIN    RINSE      SPIN ;
: RINSE   FILL    AGITATE DRAIN ; 
: FILL    FAUCETS OPEN    TILL-FULL  FAUCETS CLOSE ; 
Если изучать программу именно так, то незачем думать о стеке и других низкоуровневых деталях.

Правда Чарльз Мур рекомендовал программировать именно снизу-вверх, но на верхнем уровне должны быть вот такие слова, хорошо выражающие суть программы.

В форте любое слово не из стандартной библиотеки как-то меняет стек и уже непонятно, к каким элементам стека относится следующее.

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

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Если изучать программу именно так, то незачем думать о стеке и других низкоуровневых деталях.

Только до тех пор, пока слова не требуют аргументов и не возвращают аргументы.

FAUCETS OPEN TILL-FULL FAUCETS CLOSE

Вот уже здесь некоторое время думал, это

(progn
  (OPEN 'FAUCETS)
  (TILL-FULL)
  (CLOSE 'FAUCETS))

или

(progn
  (TILL-FULL 'OPEN 'FAUCETS)
  (CLOSE 'FAUCETS))

или

(progn
  (OPEN 'FAUCETS)
  (CLOSE 'FAUCETS 'TILL-FULL))

Предполагаю первый вариант, но это не точно.

monk ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Может и не менять стек, вообще так ли это надо для чтения кода?

Может. Также, как функция в лиспе может не иметь аргументов и не возвращать значения.

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

Например, https://docs.racket-lang.org/reference/file-ports.html#%28def._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._open-output-file%29%29

Предполагаю только вариант с подготовкой полей структуры параметров в переменной и передачей в слово имени файла и параметров.

monk ★★★★★
()
Ответ на: комментарий от monk
  • определён в стандартной библиотеке

В форте + тоже определён в стандартной библиотеке и тоже в любом случае складывает два числа на стеке.

Для лиспа достаточно знать головную форму для понимания структуры

Недостаточно. Начать хотя бы с того что головное слово может быть forth и далее программа на форте.

no-such-file ★★★★★
()
Ответ на: комментарий от monk

Только до тех пор, пока слова не требуют аргументов и не возвращают аргументы.

На верхнем уровне они понятны интуитивно, потому что пишутся почти человеческим языком.

Вот уже здесь некоторое время думал, это ...

Все очень просто, 1) существительные это данные, глаголы это слова, 2) передача функции как атома требует той же кавычки что и в лиспе (')

Следовательно вариант перевода OPEN, TILL-FULL в форму 'OPEN, 'TILL-FULL невозможен, только если бы они были записаны как ' OPEN, ' TILL-FULL.

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

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от no-such-file

В форте + тоже определён в стандартной библиотеке и тоже в любом случае складывает два числа на стеке.

В форте в 5 f 5 g + слово g может означать «не исполнять следующее слово».

Начать хотя бы с того что головное слово может быть forth и далее программа на форте.

И? Если ты знаешь это головное слово, то далее в скобках ожидаешь программу на форте.

P. S. В Common Lisp можно делать извращения подобные фортовским, переопределяя таблицы чтения, но встречается такое очень редко.

monk ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Следовательно вариант перевода OPEN, TILL-FULL в форму ’OPEN, ’TILL-FULL невозможен, только если бы они были записаны как ’ OPEN, ’ TILL-FULL.

FAUCETS ведь трактуется как ’FAUCETS (некая константа для OPEN/CLOSE)? Ладно, считай, что в примерах выше нигде кавычки нет.

(progn
  (OPEN FAUCETS)
  (CLOSE FAUCETS TILL-FULL))

существительные это данные, глаголы это слова

TILL-FULL это существительное или глагол?

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

В любом случае там находится значение. Статическая типизация не сильно сужает возможный диапазон значений. Имя переменной информативнее.

monk ★★★★★
()
Ответ на: комментарий от monk

Предполагаю только вариант с подготовкой полей структуры параметров в переменной и передачей в слово имени файла и параметров.

Можно вместо аргументов сделать структуру описывающие все нужные атрибуты открытия файла, и функции для назначения аттрибутов. Ну вот выдуманный многословный пример что бы было понятнее:

\ Аттрибуты задаются через функции (fod attr -> fod)
"C:\ya-i-kot.jpeg" create-file-open-descriptor 
  READ +file-open-mode 
  BINARY +file-open-mode
  "UTF-8" +file-encoding

\ В стеке сейчас file-open-descriptor
open-file

\ В стеке теперь только хендл открытого файла

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от monk

FAUCETS ведь трактуется как ’FAUCETS (некая константа для OPEN/CLOSE)?

А зачем кавычка то? Ты же при обращении к константе определенной через defconst не ставишь кавычку.

TILL-FULL это существительное или глагол?

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

Статическая типизация не сильно сужает возможный диапазон значений. Имя переменной информативнее.

Если только в венгерской нотации...

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от monk

имхо можно использовать форт как обычный «инфиксно » префиксный язык + постоянной опцией наличия на вытянутой руки возможности прикручивания не стандартных структур передачи управления (ибо отдельный стек извратов это позволяет делать элементарно)

т.е. есть пространство в котором обычный скажем algol-like синтаксис и семантика

с возможностью создания процедур которые [ ну подобно cи longjump setjump которые фактически притаскивают в обычный последовательный си эти самые сопрограммы(корутины) через магию с осью ] делают например выход из вложенных циклов на несколько уровней вверх

у Вирта в cacm есть статья когда было модно определять семантику синтаксиса на ходу - определение Эйлера через более ранний алгол

qulinxao3 ★☆
()
Ответ на: комментарий от monk

слово g может означать «не исполнять следующее слово».

quote передаёт тебе привет

далее в скобках ожидаешь программу на форте

Или «как будто» на ЛИСПе, но не совсем.

слово g может означать «не исполнять следующее слово».

Может означать, а может не означать.

Если ты знаешь это головное слово

Вот именно. Нужно знать все слова. Как и в форте. В (x (y 1) (z 2)) эти самые (y 1) и т.д. могут и не означать никакой «структуры».

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от MOPKOBKA

А зачем кавычка то? Ты же при обращении к константе определенной через defconst не ставишь кавычку.

Через defconst там какое-то число или строка. Я предположил, что FAUCETS = предмет, на который направлено действие OPEN. Если это количество, тогда, конечно, без кавычки.

даже если считать что это аргумент для CLOSE, то аргументы должны наоборот идти.

Почему? ( условие-закрытия предмет-закрытия -- ) не может быть?

На русском уж точно странно звучать будет.

Любая фраза на форте звучит на русском странно.

Если только в венгерской нотации…

Хочешь сказать, что для тебя информативнее

save : Int String String -> Int

по сравнению с

(defun save (db name surname) ... error-code)

?

monk ★★★★★
()
Ответ на: комментарий от no-such-file

quote передаёт тебе привет

Вот в лиспе, если f или g вдруг quote, то на суммирование они влияние оказать не могут. А в форте легко.

Может означать, а может не означать.

Разумеется. Но в форте уже в стандартной библиотеке куча слов, которые меняют чтение следующего.

Вот именно. Нужно знать все слова.

Нужно знать головное. Если головное +, то вне зависимости от функций внутри это будет последовательность результатов их выполнений. Поэтому, если я не знаю, что такое f и g я могу спокойно понять дальнейшую программу.

В форте приходится надеяться на то, что правильно расставлены отступы, переносы и комментарии соответствуют программе.

Когда так, понять можно:

\ Аттрибуты задаются через функции (fod attr -> fod)
"C:\ya-i-kot.jpeg" create-file-open-descriptor 
  READ +file-open-mode 
  BINARY +file-open-mode
  "UTF-8" +file-encoding

\ В стеке сейчас file-open-descriptor
open-file

Когда так, уже без шансов:

"C:\ya-i-kot.jpeg" create-file-open-descriptor 
  READ +file-open-mode BINARY 
  +file-open-mode "UTF-8" 
+file-encoding open-file

В лиспе по скобкам всегда можно (автоматически) восстановить правильную структуру программы.

monk ★★★★★
()
Ответ на: комментарий от monk

Это сила и одновременно проблема форта. Каждый фортист развивает словарный запас именно в том направлении, какое ему ближе и удобней. То есть у каждого фортиста получается свой форт, на котором ему удобней выражать свои мысли.

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

BRE ★★
()
Ответ на: комментарий от BRE

Каждый фортист развивает словарный запас именно в том направлении, какое ему ближе и удобней.

Это и у лисперов наблюдается. lovesan за это периодически на разработчиков библиотек ругается.

Разница именно в подходе сверху-вниз и снизу-вверх. В лиспе принято сначала обрисовать общий алгоритм и потоки данных в нём, а в форте принято сначала написать кирпичики своего DSL, а уже потом смотреть, что из них можно собрать. Зато эти кирпичики менее ограничены.

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

Команды на форте были. На форте очень сложно писать слова с определением больше, чем на несколько десятков строк. Поэтому, если программа декомпозируется на простые кусочки, её удобно писать, а если куски сложные, то на форте писать становится очень сложно, приходится комментариями указывать промежуточные состояния и надеяться, что не ошибся. Например, https://rosettacode.org/wiki/Transportation_problem на форте нет.

monk ★★★★★
()
Ответ на: комментарий от monk

Разница именно в подходе сверху-вниз и снизу-вверх. В лиспе принято сначала обрисовать общий алгоритм и потоки данных в нём, а в форте принято сначала написать кирпичики своего DSL, а уже потом смотреть, что из них можно собрать. Зато эти кирпичики менее ограничены.

Вот с этим я не согласен. :) Поэтому разделяю проектирование и реализацию программы. Нельзя спроектировать программу снизу вверх, проектирование все равно происходит сверху, а вот реализовывать можно как снизу вверх, так и наоборот.

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

BRE ★★
()
Ответ на: комментарий от monk

Но в форте уже в стандартной библиотеке куча слов, которые меняют чтение следующего.

Это необязательная черта форта. Она больше нужна для разработчиков языка, чем для прикладных программистов. Ее можно вырезать, по мнению Чарльза Мура суть форта от этого не исчезнет, вообще он критиковал ANS Forth за то что он раскрывает слишком много деталей, которые не особо полезны рядовому программисту. И критиковал различные слова которые играются с временем компиляции, но не помню точное название слова из стандарта, вроде слова для переноса со времени компиляции на время исполнения.

Когда так, уже без шансов:

Почему? +file-open-mode должен принимать аргумент со стека, иначе READ остается заброшенным.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от monk

На форте очень сложно писать слова с определением больше, чем на несколько десятков строк.

Считается плохой практикой, и даже не только в форте.

приходится комментариями указывать промежуточные состояния и надеяться, что не ошибся

Зачем надеятся? Там же eval-цикл как в Lisp, одно из преимуществ Forth.

Но это считается чертой начинающего программиста, или того кто не хочет писать на Forth. Чарльз Мур не советует доводить слова до такого состояния, когда нужно оперировать сильно более чем 3 значениями. В его процессорах вообще максимум 16 значений на стеке, и он сказал что это «с запасом».

Не ожидается что Forth программист должен исполнять моментально операции вращающие-перемещающие 20 аргументов по стеку.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Считается плохой практикой, и даже не только в форте.

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

BRE ★★
()
Ответ на: комментарий от BRE

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

Читал учебник по форту. Неудобно получается. Потому что при реализации наверняка выяснится, что это разделение оказалось неправильным. Если не брать совсем тривиальные случаи.

Поэтому разделяю проектирование и реализацию программы.

Форт и лисп — два языка, на которых можно реализовывать программу без проектирования. Финны, авторы учебника по лиспу, приводили хорошую аналогию: на других языках мы строим здание и нам нужен проект, даже для того, чтобы правильно сформировать фундамента; на лиспе мы выращиваем дерево, то есть начинаем с минимально работающей версии, а потом по мере расширения дописываем корни и ветви. Форт также позволяет писать без проектирования, но из-за влияния слов друг на друга лучше определять согласованный словарь, а не пытаться конкретную задачу разбить на слова.

monk ★★★★★
()
Ответ на: комментарий от MOPKOBKA

«int db» намного информативнее чем «db», да.

Вот ничуть. Когда это db получается из open-db и используется только в save и load, абсолютно не важно, int там или строка или вообще какая-то структура.

Зато int db провоцирует проверить что будет, если туда передать число, которое получено не из open-db. Ведь типизированная функция должна работать корректно со всеми значениями указанного типа.

monk ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Почему? +file-open-mode должен принимать аргумент со стека, иначе READ остается заброшенным.

READ может быть аргументом для open-file. А +file-open-mode может класть настройку, которую потом модифицирует BINARY.

monk ★★★★★
()
Ответ на: комментарий от monk

Вот ничуть.

А по моему сильно, и еще понятно стоит ли передавать через регистр или через указатель. Я вот сторонник венгерской нотации, и вижу пользу от указания struct/enum/union в типах С, вместо переназначения на однотокенное имя через typedef.

В случаях когда db это хендл, то лучше сделать typedef конечно, как сделано для FILE. В других случаях лучше видеть тип.

Зато int db провоцирует проверить ...

Не знаю кто так делает, но проверку на тип в JavaScript видел. Функции начинаются с if typeof ...

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от monk

По DSL мне кажется важная идея, которую многие упускают, это то что его можно собирать даже из языка который не поддерживает макросы и читатели. Пример со стиральной машиной использует только слова и переменные, и я считаю такой DSL может быть намного лучше, если конечно есть возможность его реализовать. Иногда без макросов и читтателей никуда.

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от MOPKOBKA

Там же eval-цикл как в Lisp, одно из преимуществ Forth.

Кусок из середины функции в него не запихнуть.

В его процессорах вообще максимум 16 значений на стеке, и он сказал что это «с запасом».

А как он делает рекурсивный бинарный поиск?

Не ожидается что Forth программист должен исполнять моментально операции вращающие-перемещающие 20 аргументов по стеку.

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

Я про то, что внутри длинной функции состояние держать в уме достаточно сложно. И даже не длинной: посмотри на построчные комментарии к b64enc: https://rosettacode.org/wiki/Base64_encode_data#Forth

monk ★★★★★
()
Ответ на: комментарий от MOPKOBKA

даже из языка который не поддерживает макросы и читатели

Если речь про Форт, то IMMEDIATE это как раз режим макросов.

На языке совсем без макросов DSL приходится делать только из функций. Иногда тоже получатся (например, C++ Boost.spirit).

monk ★★★★★
()
Ответ на: комментарий от monk

Кусок из середины функции в него не запихнуть.

Скопипастить можно, проследить стек, запустить саму функцию.

А как он делает рекурсивный бинарный поиск?

Бинарный поиск знаю, а что такое рекурсивный бинарный поиск? Для этих чипов разрабатывались какие то мультимедиа-решения, если правильно помню то кодирование/декодирование видео, и работа с jpeg демонстрировалась.

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

10 уже слишком много, тупо нельзя обратиться к первому аргументу.

И даже не длинной: посмотри на построчные комментарии к b64enc

Этот пример легко читается без комментариев, просто интерпретируя стандартные и основные слова в голове. Вообще используя передовые практики Forth, его легко упростить, используя например адресный регистр, но пример все же для ANS Forth пишется, поэтому можно использовать просто переменные, и убрать эти rot rot.

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от monk

Так никто не пишет

Как так? Может же быть

Так, что аргумент для функции, добавляется в стек задолго до ее вызова. Исключения когда он приходит из аргумента, там он мог быть вычислен заранее.

даже из языка который не поддерживает макросы и читатели

Если речь про Форт, то IMMEDIATE это как раз режим макросов.

Нет, в ANS Forth все поддерживается на высоком уровне, а автор SP-Forth даже в своих веб-программах (всякие почтовики и серверы) парсил http и другие протоколы через читатель Forth. Есть ли примеры в Lisp чему то подобному?

Я про любой предполагаемый язык где возможности читателя или IMMEDIATE ограниченны или отсуствуют.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от MOPKOBKA

Я не участник вашего спора, и благодаря Форту начал писать на Лиспе. Но заметно, что когда @monk пишет о качествах, которые в лиспе автоматически есть, ты на это отвечаешь качествами, которые в программе на Forth должны возникнуть в результате того, что программист будет выполнять какие-то руководства по стилю. А их ведь можно не выполнять и наверняка, как обычно, те, кто пишут правила, живут по исключениям. Т.е. я склоняюсь к тому, что лисп таки более читаем.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Я не согласен, так как ты не привел конкретного примера, то остановимся на стеке, и тем что там могут быть свои проблемы в коде. В Lisp я видел код который не использует структур, и состоит из бесконечных car car cdr cdr car car для эмуляции полей. По моему в таком ничуть не легче навигироваться чем в Forth.

Точно так же легко заполнить не то поле, и программа посыпется. А потом ищи в каком участке поле неправильно заполнилось.

Lisp дает ограничение области аргументов из коробки, если ты пишешь только функции, да. С этим я согласился еще пару дней назад выше по треду. В остальном я не согласен.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 4)
Ответ на: комментарий от MOPKOBKA

Дополню, я считаю два языка абсолютно ужасны для командной работы, или начинающих программистов, и проблемы в целом очень похожи, просто немного разного вида. Без подготовки я не могу читать Lisp, без подготовки monk не может читать Forth. Считаю тот же алголо-си-синтаксис читается даже неподготовленным человеком намного лучше. А уж какие средства для командных работ развиты в других языках...

Так что для лисперов, Forth это идеальный язык для того что бы взглянуть на Lisp, с точки зрения программиста который интересовался только мейнстримными языками.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от MOPKOBKA

Скопипастить можно, проследить стек, запустить саму функцию.

Тогда логичнее делать отдельным словом.

Бинарный поиск знаю, а что такое рекурсивный бинарный поиск?

Значение в двоичном дереве по ключу.

(defun search (tree the-key)
  (cond
    ((null tree) nil)
    ((eq (key tree) the-key) (val tree))
    (t
      (or (search (left tree) key) (search (right tree) key))))
monk ★★★★★
()
Ответ на: комментарий от monk

Значение в двоичном дереве по ключу.

А зачем его полностью сканировать? По коду вижу сканируется все, сначала левая часть, потом правая. В таком случае проще запустить цикл по массиву где хранятся элементы дерева.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Так, что аргумент для функции, добавляется в стек задолго до ее вызова.

Тогда как было бы, если надо вызвать

(open-file 
  (create-file-open-descriptor "C:\ya-i-kot.jpeg")   
  READ 
  (+file-encoding 
    "UTF-8" 
    (BINARY +file-open-mode)
    +file-open-mode))

?

monk ★★★★★
()
Ответ на: комментарий от monk

Они изначально в массиве. Дерево это интерпретация массива. А сканирование массива просто проще и быстрее.

MOPKOBKA ★★★★★
() автор топика
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

Так что для лисперов, Forth это идеальный язык для того что бы взглянуть на Lisp, с точки зрения программиста который интересовался только мейнстримными языками.

В лисп тоже после мейнстримных обычно приходят.

В форте удобнее то, что есть возможность делать слова, которые влияют на следующие. В лиспе периодически появляются страдальцы, которые хотят, чтобы было как в питоне

(my-if условие
  команды
  ...)
(my-elsif условие
  команды
  ...)
(my-else
  команды
  ...)

Заставить макрос влиять на другой макрос почти невозможно. В форте этого ограничения нет. Плюс возможность возврата набора значений аргументами следующей функции (как если бы в лиспе по-умолчанию всё вызывалось через multiple-value-call).

monk ★★★★★
()
Ответ на: комментарий от monk

Нужно вынести создание структуры в отдельное слово или тогда уж READ swap open-file что бы поближе быть к слову, но ты идею мне кажется не так понял, давай запишу в С синтаксисе то что я представлял:

CreateFileDescriptor desc = new CreateFileDescriptor("C:\ya-i-kot.jpeg"); 
desc.setOpenModeAttr("READ", true);
desc.setOpenModeAttr("BINARY" true);
desc.setFileEncoding("UTF-8");
FILE f = OpenFile(desc);
MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от MOPKOBKA

Свои проблемы могут быть, но надо рассматривать однородные проблемы. Вариант с car и cdr неоднороден с тем, что любое слово может делать со стеком что угодно. Впрочем, я плоховато знаю Форт, чтобы реально на уровне тут разговаривать. Хотя первые свои программы я писал (на бумажке) для БЗ-34, видимо, это что-то похожее на Форт.

den73 ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Они изначально в массиве. Дерево это интерпретация массива. А сканирование массива просто проще и быстрее.

Вот дерево: https://rosettacode.org/wiki/Tree_traversal#Forth

Как из tree получить массив, интерпретацией которого оно является?

monk ★★★★★
()
Ответ на: комментарий от monk

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

MOPKOBKA ★★★★★
() автор топика
Ответ на: комментарий от MOPKOBKA

Алголоподобная запись кажется хорошей, но в ней есть грабли, во всяком случае, в языках типа Си без отдельного булевого типа. Для сложных логических выражений внезапно лисп оказывается удобнее. Проверять, лучше ли алголоподобная запись, нужно на действительно неподготовленном человеке, а где такого взять? В школе уже учат алгербру, и это - самая мутная часть алголоподобного синтаксиса. Конечно, да, в лиспе многовато лишних скобок. Но в целом я не согласен, что лисп ужасен для начинающих или для командной работы. Проблемы есть, но решаемые. Опять же, о каком лиспе идёт речь. Про Форт не скажу, но мне кажется, Форт - прежде всего для оптимизации по размеру, этакий ассемблер. Т.е. у него узкая ниша, где он нужен. Лисп же универсален.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)