Ремесло программиста

Объявление

форум на движке phpBB доступен для тестирования
www.strategia.space
www.strategia.space/forum/
по предложению Лиса - канал на Matrix - #remdev:matrix.org

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Валентина » Описание языка


Описание языка

Сообщений 31 страница 43 из 43

31

Павиа написал(а):

Породить объект и выйти из функции так что-бы он жил?

Если внутри функции создать новый поток/нить выполнения, то у него/неё создастся новый стек, а там будут новые объекты, пока нить не завершится. Но я не заметил многопоточности (операции запуска нити) в описании языка.

32

Породить объект и выйти из функции так что-бы он жил?

Создайте объект до входа в функцию.

На этом половину ООП базируется: инструктирование, фабрики, IoC и тд.

Вам не угодишь. Когда говоришь, что есть разница, Вас не устраивает и Вы ищите общие черты. Когда находятся расхождение, Вам опять не то :). В функциональном программировании как-то живут с таким положением дел и никто не жалуется. Я не вижу проблем в создании объекта раньше функции.
создать подсистему х
х=какая_то_функция_типа_фабрика()

33

Осталось понять, почему в жизни так не делают. Должна быть причина.

34

Осталось понять, почему в жизни так не делают. Должна быть причина.

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

35

ВежливыйЛис
Человек не владеет инверсией управления. Но и функциональная парадигма не мешает. Придётся в функцию добавить ещё один параметр и рекурсивно вызывать функцию. Что будет приводит к громоздким конструкциям. Или по ходу патчить функцию то туда то обратно.

36

ВежливыйЛис написал(а):

Осталось понять, почему в жизни так не делают.

особенности коллективного труда

Павиа написал(а):

Придётся в функцию добавить ещё один параметр и рекурсивно вызывать функцию.

Кол-во передач сокращается при возможности вложения с видимостью вышестоящих данных.

37

utkin написал(а):

В функциональном программировании так делают. Наверно тоже есть причина.

В функциональном программировании существуют функции высших порядков, у которых в параметры можно передать другую функцию. А такая подстановка равна созданию объекта (замыкания) в куче. Зря что-ли говорят, что в функциональном программировании функция - это первоклассный объект? А где куча, там мусор. Лисп тому примером - вроде функциональный язык, а сборщик мусора есть.

у тебя, функций высшего порядка нет.

https://softwareengineering.stackexchan … collection

Вот тут пишут, что делают функциональные языки без GC:
https://stackoverflow.com/questions/995 … -collector
(They experimented with purely region-based memory management (i.e. no garbage collector))

А тут пишут, что регионы получаются с излишне большим временем жизни (приводят к перерасходу памяти по сравнению с GC):
https://en.wikipedia.org/wiki/Region-ba … management
Systems using regions may experience issues where regions become very large before they are deallocated and contain a large proportion of dead data

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

Отредактировано ВежливыйЛис (2017-07-18 01:46:38)

38

В функциональном программировании существуют функции высших порядков, у которых в параметры можно передать другую функцию. А такая подстановка равна созданию объекта (замыкания) в куче. Зря что-ли говорят, что в функциональном программировании функция - это первоклассный объект? А где куча, там мусор. Лисп тому примером - вроде функциональный язык, а сборщик мусора есть.
у тебя, функций высшего порядка нет.

Почему нет? Во-первых, функции системы и соответственно в них можно добавлять функции. Во-вторых, анонимных функций нет, но внутри функций на этапе написания программы также можно объявлять функции. То есть Вы просто на время выполнения функции добавляете в нее новую.  С точки зрения реализации такой модели функция будет иметь список ссылок, доступных для поиска вложенных функций. Я обдумываю как это должно выглядеть синтаксически, там ниже по тексту еще не дописано, но есть раздел "Спецификаторы функций" (или как-то так) - это такие вот метапараметры, которые будут описывать характер параметров функции. Ну грубый пример:
функция Сумма( Параметр1 как ряд) Ряд указывает, что Параметр1 это последовательность аргументов, то есть функцию можно будет вызвать так: сумма(х, у, z)

Или функция Сортировка(сравнение как функция, данные).  То есть на время исполнения в область видимости Сортировки будет добавлена функция сравнение. Я еще сам не до конца продумал, но в целом будет выглядеть как-то так. Вообще Вы сильно далеко в глубь копаете. Вопрос хранения данных это проблема реализации языка, а не проблема алгоритма. Иными словами как реально располагаются данные внутри модели это не дело программиста. Все что ему нужно знать, это то как описать дерево систем, чтобы достигнуть результата. Все остальное должен делать интерпретатор (и если повезет, то и компилятор).

Вдруг твой язык - это прорыв в этой области.

Сильно сомневаюсь  :crazyfun:  Основное правило в языке - максимально общие правила для всех и минимум индивидуальных костылей. Поэтому и типов данных всего два - строки и системы.

Человек не владеет инверсией управления.

Это тоже копание в реализации, а не в языке. Я уже привел пример - Вы можете заранее создать систему, а потом натравливать на нее свои паттерны. Эффект будет абсолютно одинаковый. В чем проблема? Вы создаете на фабрике объект. Я предлагаю его на фабрике модифицировать.

Но и функциональная парадигма не мешает. Придётся в функцию добавить ещё один параметр и рекурсивно вызывать функцию. Что будет приводит к громоздким конструкциям. Или по ходу патчить функцию то туда то обратно.

О чем это Вы? Дайте условный пример, какой-нибудь, чтобы понять.

Новая версия: https://yadi.sk/i/UOoaULEi3L9nsu

39

Породить объект и выйти из функции так что-бы он жил?

Создайте объект до входа в функцию.

Или функция должна уметь создавать объекты в стеке той функции, которая её вызвала: можно посмотреть тут и тут: Размещение объектов переменной длины с использованием двух стеков и Реализация двухстековой модели размещения данных.

40

Или функция должна уметь создавать объекты в стеке той функции, которая её вызвала

Да видите, еще решение. Но опять же это реализация возможностей языка, а не сами возможности.

41

Юрий написал(а):

Или функция должна уметь создавать объекты в стеке той функции, которая её вызвала: можно посмотреть тут и тут

utkin написал(а):

Да видите, еще решение.

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

42

Решение задачи в целом в сравнении с решениями для частных случаев выигрывает в универсальности. Но зачастую проигрывает по другим критериям, типа простоты и скорости. Например, однопоточное приложение – частный случай многопоточного. И для одного потока проще решать означенную выше проблему без кучи.

43

Юрий написал(а):

Решение задачи в целом в сравнении с решениями для частных случаев выигрывает в универсальности. Но зачастую проигрывает по другим критериям, типа простоты и скорости. Например, однопоточное приложение – частный случай многопоточного. И для одного потока проще решать означенную выше проблему без кучи.

Заявленная пара стеков не решает проблему управления памятью дальше одного уровня передачи - потребуется перекопировать по стеку несколько раз, что как-то не похоже на "скорость и простоту". Для сравнения: в Паскале есть видимость стековых переменных во вложенных функциях, ничего не требуется передавать вообще, достаточно объявить и заполнить переменную на нужном уровне.
Но проще-то как раз обойтись без стека вообще, особенно вначале. А для сравнения по скорости надо учитывать много факторов, начиная с кратности решения задачи, нагрузки на среднестатистическую систему использования, задержки м/у действиями пользователя. Да и запросто может оказаться, что многопоточное на куче обойдёт однопоточное без её применения.


Вы здесь » Ремесло программиста » Валентина » Описание языка