Re[10]: Expression Tree для описания алгоритмов
От: batu Украина  
Дата: 19.05.10 16:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:


N>>>>Потому что сейчас есть Curry.


VD>>>А ты сам то это чудо используешь?


B>>Это не аргумент если вопрос задан в теоретической плоскости.


VD>А я говорил, что это аргумент?

VD>Это вопрос!

B>>В этом смысле очень даже решает проблему. Здесь и алгоритмов не надо писать. Этим занимается компьютер. Беда только в эффективности. Думаю если объединить не две (как в carry) а три парадигмы (включая императивную) хорошо получится..


VD>У меня были мысли включить аналог системы вывода правил пролога в Немерле в виде макросов (или даже в ядро второй версии языка). Но это не малый объем работы. Плюс нужны знания о том как реализовать алгоритм вывода эффективно, так как простой перебор с откатами не самое лучшее решение с точки зрения эффективности. Как я понимаю в реальных компиляторах и интерпретаторах Пролога используется море эвристик и прочих оптимизаций.


VD>Так что если найдутся люди которые хотя бы помогут реализовать алгоритмы вывода эффективно, то мы этим обязательно займемся. А если кто-то еще и захочет взяться за реализацию микро-пролога в виде макросов немерла, то я постараюсь организовать ему всяческую поддержку.


VD>Так что если есть желающие, милости просим!

Думал ответишь.. Понимаю что это серьезно. Но легко в виде макросов не получится. После трансляции все высказывания должны составлять среду в которой будет искаться решение (в смысле интерпретация целевых высказываний).
Re[22]: Expression Tree для описания алгоритмов
От: Тролль зеленый и толстый  
Дата: 19.05.10 18:44
Оценка:
G>В средней школе и циклов, и рекурсии даже близко не было.

Я и говорю, рекурсии не было, а циклы — были: последовательность шагов с возвратом на один из шагов назад = цикл.

ТЗИ>>1) Истинность F(n)

G>Неверно, истинность F(n) предполагаем, доказывать надо для F(N0),F(N1)... — базовые случаи

Ладно. Еще раз, более просто, надо доказать истинность двух утверждений:

1) P(1),
2) P(n) => P(n + 1).

Случай n + k не будем рассматривать, поскольку он тривиально приводится к n + 1.

Рассуждение про "предполагаемую истинность" — это всего лишь простонародное объяснение импликации.

Индукция — это всего лишь цепочка импликаций.

ТЗИ>>2) Истинность импликации F(n) => F(n + k),

G>Именно, и как это доказывается? Выражением F(n + k) через F(n) — вот тебе и рекурсия.

Необязательно. Это доказывать можно как угодно — на индукцию это не влияет.
Re[22]: Expression Tree для описания алгоритмов
От: Тролль зеленый и толстый  
Дата: 19.05.10 19:03
Оценка:
DM>...натуральные числа — это частный случай рекурсивной структуры:
DM>Nat = Zero | Succ Nat

Ну да, линейную структуру можно определить рекурсивно. То есть определить с помощью рекурсивной порождающей (определяющей) функции, как написано выше. А можно определить и не с помощью рекурсии, а с помощью порождающей циклической процедуры — последовательности шагов. Это эквивалентные представления.

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

В школьной математике нам давали нерекурсивное представление.

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

Ну вот можно взять справочник по математике за школьный курс и найти там рекурсию.
Re[23]: Expression Tree для описания алгоритмов
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.05.10 19:11
Оценка:
Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Вообще, моя первоначальная мысль была всего лишь о том, что я не могу вспомнить, чтобы я так уж часто видел (если вообще видел) в учебниках по математике, не относящихся к computer science, запись рекурсивных функций, кроме, например, факториала и специфического раздела про рекуррентные соотношения и производящие функции.


ТЗИ>Ну вот можно взять справочник по математике за школьный курс и найти там рекурсию.


Арифметическую и геометрическую прогрессии в школе не изучают? Для них таки норма выражать последующий член через предыдуший.
Re[24]: Expression Tree для описания алгоритмов
От: Тролль зеленый и толстый  
Дата: 19.05.10 19:34
Оценка:
S>Арифметическую и геометрическую прогрессии в школе не изучают? Для них таки норма выражать последующий член через предыдуший.

Да, согласен. Сам не понимаю, зачем я начал это глупое обсуждение.
Re[11]: Expression Tree для описания алгоритмов
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.10 19:48
Оценка:
Здравствуйте, batu, Вы писали:

VD>>Так что если есть желающие, милости просим!

B>Думал ответишь..

На что? Не понял.

B>Понимаю что это серьезно. Но легко в виде макросов не получится.


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

B>После трансляции все высказывания должны составлять среду в которой будет искаться решение (в смысле интерпретация целевых высказываний).


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

ЗЫ

Кстати, сам компилятор немерла использует констрэйн-солвер который является укрощенной реализацией пролога.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Expression Tree для описания алгоритмов
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.05.10 07:13
Оценка:
Здравствуйте, Тролль зеленый и толстый, Вы писали:

G>>В средней школе и циклов, и рекурсии даже близко не было.


ТЗИ>Я и говорю, рекурсии не было, а циклы — были: последовательность шагов с возвратом на один из шагов назад = цикл.

В школе? Это что за школа где такое дают? Я помню только 11 класс, такого точно не было.

ТЗИ>>>2) Истинность импликации F(n) => F(n + k),

G>>Именно, и как это доказывается? Выражением F(n + k) через F(n) — вот тебе и рекурсия.

ТЗИ>Необязательно. Это доказывать можно как угодно — на индукцию это не влияет.


Только если доказывается истинность F(n+1) без участия F(n), то и вся индукция не нужна, потому что можно для любого n доказать истинность F(N).

Если ты еще не понял: сама по себе индукция применяется именно там где есть рекурсия, иначе это не индукция получается.
Re[12]: Expression Tree для описания алгоритмов
От: batu Украина  
Дата: 20.05.10 11:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:


VD>>>Так что если есть желающие, милости просим!

B>>Думал ответишь..

VD>На что? Не понял.


B>>Понимаю что это серьезно. Но легко в виде макросов не получится.


VD>Легко не получится ни в каком виде. Но в виде макросов получится точно легче чем если делать язык с нуля.

Что значит "делать язык с нуля"?
1. Сочинять синтаксис?
2. Делать транслятор?
3. Реализовать ото что оттранслировано?

B>>После трансляции все высказывания должны составлять среду в которой будет искаться решение (в смысле интерпретация целевых высказываний).


VD>Макрос позволяет задать необходимый синтаксис и семантику. Реализацию конечно же придется писать самостоятельно.

VD>Но, если алгоритмическая сторона ясна (понятно как реализовать нужные возможности), то проблем в реализации на макросах не будет.

VD>ЗЫ


VD>Кстати, сам компилятор немерла использует констрэйн-солвер который является укрощенной реализацией пролога.

Не сомневаюсь что сочинить синтаксис и оттранслировать будет легче на какой-то базе. И парсеров хватает. Вопрос не в том. Как ты пишешь "алгоритмическая сторона ясна" так тут как раз и не ясна. В логичском программировании алгоритм строит не програмист, а сама интерпретрующая система. Т.е. если ты определил несколько функций и высказываний, то вызовом нужных по теме функций осуществялется не программист, а сама система на основе инерпретации. Совсем другой подход. Получается макрос не выполняется а на основе макросов (так ты их назвал) конструируется алгоритм во время выполнения. Иногда тупо методом перебора. Но это уже тема построения интерпретатора. И как этот интерпретатор вмонтировать в уже существующую систему я не понимаю. Он должен грузиться вместе с оттранслированной программой. С каждой? Глупо. А куда его влепить? Это должно быть средой (или виртуальной машиной) интерпретирующей наши сочиненные макросы. И не макросы это.. Макросы ж сразу в машинные (или промежуточные) команды транслируются, а нам в виртуальную машину необходимо передать именно семантическую структуру высказываний, функций и прочую матоту которая будет информацией для интерпретатора, который уже и будет строить алгоритм.
Могу сказать что я придумал как это сделать.. Но делать прийдется таки с нуля.. Но получится круче немерлы..
Re[13]: Expression Tree для описания алгоритмов
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.10 11:46
Оценка:
Здравствуйте, batu, Вы писали:

B>Что значит "делать язык с нуля"?

B>1. Сочинять синтаксис?
B>2. Делать транслятор?
B>3. Реализовать ото что оттранслировано?

И то, и другое, и третее. И еще кое-что. Язык не может жить обособленно. Он должен взаимодействовать с унивирсальынм языком. Для внешнего ДСЛ-я это еще одна проблема.

B>Не сомневаюсь что сочинить синтаксис и оттранслировать будет легче на какой-то базе. И парсеров хватает. Вопрос не в том. Как ты пишешь "алгоритмическая сторона ясна" так тут как раз и не ясна.


Раз не ясна, то "ой".

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


Я в курсе (за исключением интерпретации). Я говорил о алгоритмах которые как раз и создают код вывода, а не о самом коде вывода. Т.е. в твоей терминалогии код интерпретатора.

B> Получается макрос не выполняется а на основе макросов (так ты их назвал) конструируется алгоритм во время выполнения.


Во время выполнения — это плохой подход. Нужно конечно во время компиляции. Эдакое частичное вычисление.

B> Иногда тупо методом перебора. Но это уже тема построения интерпретатора.


Еще раз повтоюсь, что интерпретатор — это дна из возможных реализаций. И самая плохая.

B>И как этот интерпретатор вмонтировать в уже существующую систему я не понимаю.


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

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

B>Он должен грузиться вместе с оттранслированной программой. С каждой?


Зачем? Только если использована соответствующий макрос (или макробибилотека).

B>Глупо. А куда его влепить? Это должно быть средой (или виртуальной машиной) интерпретирующей наши сочиненные макросы. И не макросы это.. Макросы ж сразу в машинные (или промежуточные) команды транслируются, а нам в виртуальную машину необходимо передать именно семантическую структуру высказываний, функций и прочую матоту которая будет информацией для интерпретатора, который уже и будет строить алгоритм.


Все это нужно представлять в виде структур данных.

B>Могу сказать что я придумал как это сделать.. Но делать прийдется таки с нуля.. Но получится круче немерлы..


Думаю, что ты просто несколько узко смотришь на задачу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Expression Tree для описания алгоритмов
От: batu Украина  
Дата: 20.05.10 12:17
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:




B>>Могу сказать что я придумал как это сделать.. Но делать прийдется таки с нуля.. Но получится круче немерлы..


VD>Думаю, что ты просто несколько узко смотришь на задачу.

Обычное труднопонимание для начала. Надеюсь при более плотном общении это пройдет. Я предлагаю систему которая говорю будет круче немерлы.. Вот здесь часть высокого уровня. здесь Здесь предусмотрено все. И императивная парадигма и функциональная и логическая и формирование и редактирование документов и парсеры и вообще все. Подробности лучше обсуждать в аське. 139070664
Re[14]: Expression Tree для описания алгоритмов
От: batu Украина  
Дата: 20.05.10 12:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:


Вместо макросов немерлы там объекты класса Instruction. Есть еще объекты класса Class и Type. Class — это для объектов, Type- для значений. Ну, надеюсь почитаешь.
Re[14]: Expression Tree для описания алгоритмов
От: batu Украина  
Дата: 20.05.10 12:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:


Вот только что прочитал здесь про блоги и про вики, так в моей системе (и языке) и эти проблемы легкорешаемы и вообще весь электронный документоборот. Предлагаемый язык и система не только программы способена писать, но и создавать и редактировать документы с любыми объектами. В частности с буквами. В этом, частном случае, это текстовые документы. А может быть и страницей сайта или таблицей или базой данных. Ну, и мета-объекты (у меня просто понятия (Declaration) и много-много чего еще
Re[15]: Expression Tree для описания алгоритмов
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.10 16:08
Оценка:
Здравствуйте, batu, Вы писали:

B>Здравствуйте, VladD2, Вы писали:


VD>>Здравствуйте, batu, Вы писали:


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


Документы да еще и "В частности с буквами." — это коечно здорово. Только вот есть два вопроса которые надо решить.
1. Нужно ли это хоть кому-то кроме тебя?
2. Когда это дело можно будет использовать? Да и вообще появится ли оно хоть когда нибудь.

Я читал твои описания, но энтузиазма что-то все это у меня не вызвало. Разговоры о шрифтах, цветах и т.п. вообще какие-то бредовые. Я тут поднимал вопрос о том не использовать ли в Немерле юникодные символы и народ в один голос сказал — "нет", так как код нужно еще передавать через почту и публиковать в форумах где еще далеко не везде поддерживается юникод. К тому же мало кто хочет связываться с символами которых нет на клавиатуре. А уж шрифты и цвета — это просто смешно. Есть проверенные решения. Цвета уже задействованы для выделения синтаксических конструкций. Большое количество шрифтов на экране будет коробить глаз и путать людей.о

В обще, идея добавить в виде макро-библиотеки в существующий и состоявшийся язык поддержку логического программирвоания вполне реалистична и интересна. Это можно сделать за реальное время и начать получать выгоду. А затевать еще один язык с сумбурными целями и даже в упор не заметной перспективо — это слишком безрассудно.

Так что ты конечно занимайся своим языком. Может быть чего-то из этого и выйдет. Но лично мне нужен иструмент здесь и сейчас. Причем не умозрительный, а соврешенно реальный и проверенный на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Expression Tree для описания алгоритмов
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.10 16:22
Оценка:
Здравствуйте, batu, Вы писали:

B>Я предлагаю систему которая говорю будет круче немерлы.


"Будет" не канает. Ты сначал сделай. Потом попробуй хотя бы человек 5 убедить в правоте своего утверждения, а потом уже можно будет о чем-то говорить.

Пока что Немерл самый мощьй язык для дотнета. И один из самых мочных из существующих на сегодня и пригодных для реального использования. А твой язык пока что только план. Причем уже даже на уровен плана он вызвает массу сомнений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Expression Tree для описания алгоритмов
От: batu Украина  
Дата: 20.05.10 16:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:


B>>Здравствуйте, VladD2, Вы писали:


VD>>>Здравствуйте, batu, Вы писали:


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


VD>Документы да еще и "В частности с буквами." — это коечно здорово. Только вот есть два вопроса которые надо решить.

VD>1. Нужно ли это хоть кому-то кроме тебя?
Вот тебе нужно. И многим нужно. Только все пытаются обойтись тем что есть. Не всегда это возможно в принципе. А зачастую стоит столько же сколько новую систему сделать.
VD>2. Когда это дело можно будет использовать? Да и вообще появится ли оно хоть когда нибудь.
Надеюсь появится. Когда не знаю. Не только от меня зависит. И от тебя тоже.

VD>Я читал твои описания, но энтузиазма что-то все это у меня не вызвало. Разговоры о шрифтах, цветах и т.п. вообще какие-то бредовые. Я тут поднимал вопрос о том не использовать ли в Немерле юникодные символы и народ в один голос сказал — "нет", так как код нужно еще передавать через почту и публиковать в форумах где еще далеко не везде поддерживается юникод. К тому же мало кто хочет связываться с символами которых нет на клавиатуре. А уж шрифты и цвета — это просто смешно. Есть проверенные решения. Цвета уже задействованы для выделения синтаксических конструкций. Большое количество шрифтов на экране будет коробить глаз и путать людей.о

Не зацикливайся на цветах и шрифтах. Это просто как вариант предложил. Можно и без него обойтись. Я ж не квадратный. Если будет выглядить попугаисто, конечно будет смешно. Тут дизайнерам надо потрудиться. я ни на чем не наставиваю.

VD>В обще, идея добавить в виде макро-библиотеки в существующий и состоявшийся язык поддержку логического программирвоания вполне реалистична и интересна. Это можно сделать за реальное время и начать получать выгоду. А затевать еще один язык с сумбурными целями и даже в упор не заметной перспективо — это слишком безрассудно.


VD>Так что ты конечно занимайся своим языком. Может быть чего-то из этого и выйдет. Но лично мне нужен иструмент здесь и сейчас. Причем не умозрительный, а соврешенно реальный и проверенный на практике.

И ты пробуй. Это именно тот случай когда заново сделать будет проще. Но ты ж не повериишь
Re[17]: Expression Tree для описания алгоритмов
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.10 17:38
Оценка: 8 (1)
Здравствуйте, batu, Вы писали:

VD>>Документы да еще и "В частности с буквами." — это коечно здорово. Только вот есть два вопроса которые надо решить.

VD>>1. Нужно ли это хоть кому-то кроме тебя?
B>Вот тебе нужно.

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

B>И многим нужно. Только все пытаются обойтись тем что есть.


Я не заметил ни одного одобрительного отзыва на твои описания. Я плохо смотрел?

B>Не всегда это возможно в принципе. А зачастую стоит столько же сколько новую систему сделать.


Сделать что-то с нуля по определителю сложнее чем сделать часть.

Что же до языка, то их вообще нельзя проектировать сверху вниз. Точнее можно, но результат известен заранее. Он будет академическим и в лучшем случае отдельные идеи из него через много лет попадут в какой-нибудь реально живущий язык.

Вот прекрасный пример — Эфил. Это в общем-то весьма простой язык который был создан ради реализации концепции "Design by contract" придуманной его автором (Меером). Язык так и не получил серьезной популярности. Это привело к тому, что идеи (отличные идеи, надо сказать!) заложенные в его языке пробивали себе дорогу к реальным программистам последние 25 лет. И только в этом коду эти идеи (в усеченном виде) попали в дотнет, а значит к конечному потребителю.

Еще один замечательный пример — язык Алгол. Он вообще бы спроектирован учеными и так и не стал использоваться на практике. Более приземленный Паскаль вобрал множество идей из Алгола и стал популярным. Причем реальную популярность он получил когда за него взялся Хейльсберг.

B>Не зацикливайся на цветах и шрифтах. Это просто как вариант предложил. Можно и без него обойтись. Я ж не квадратный. Если будет выглядить попугаисто, конечно будет смешно. Тут дизайнерам надо потрудиться. я ни на чем не наставиваю.


Ну, так советую просто вкинуть эти идеи. Кроме веселья они ничего не дают. Тем более что уже есть КомпонетПаскаль который имеет встроенную среду позволяющую раскрашивать исходники вручную. Выглядит это страшно.

VD>>Так что ты конечно занимайся своим языком. Может быть чего-то из этого и выйдет. Но лично мне нужен инструмент здесь и сейчас. Причем не умозрительный, а совершенно реальный и проверенный на практике.

B>И ты пробуй. Это именно тот случай когда заново сделать будет проще. Но ты ж не повериишь

А я и не верю. И собственно хочу заняться. Но не изобретением нового мира с нуля, а улучшением того что имеется.

С нуля лучше писать реализацию компилятора. Тут действительно работает принцип "проще написать за нова нежели переписать код с ошибками". А вот дизайн языка точно нельзя делать с нуля. На свете есть только один реальный язык созданный с нуля — Фортран. Да и то возможно я ошибаюсь. Все остальные языки черпали идеи из других языков. И самые успешные языки оказались те которые грамотно сочленяли эти идеи внося минимум нового.

У меня есть идея (и желание) написать новую версию Немерла. Но задачи этого проекта не создать новый язык (или сильно отличающийся), а развить и улучшить то хорошее что уже есть в немерле.
Вот краткий план того что планируется:
1. Снять ограничения на изменение синтаксиса. Это будет достигнуто за счет перевода компилятора и макросов на PEG.
2. Реализовать сам язык полностью на макросах. Парсера как такового не будет вовсе. Вместо этого конструкции языка будут оформляться в виде макросов нового поколения. Это так же уменьшит базу языка и позволит автоматически генерировать документацию по нему.
3. Доработать систему типов введя поддержку зависимых типов и усилив возможности ограничений (констрэйнов).
4. Упростить разработку макросов и DSL-ей на их базе.
5. Сделать компилятор модульным (разделить его на ряд библиотек которые можно будет использовать по отдельнсоти).
6. Сделать компилятор многопоточным, а АСТ и другие структуры данных доступные макросам версионными. Это с одной стороны ускорит компилятор, а с другой облегчит поддержку языка в IDE.
7. Отказаться от System.Reflection.Emit, а для получения метаданных и генерации кода использовать набор абстракций (интерфейсов и т.п.) позволяющий легко менять нижележащую библиотеку. По умолчанию использовать CCI Matadata.
8. Модернизировать алгоритм вывода типов с тем чтобы а) позволить выводить типы для разных функций в разных потоках, б) упростить реализацию, в) устранить имеющее место дублирование кода. В итоге вывод типов должен стать быстрее, надежнее и проще поддаваться модификации. Такие вещи как алгоритм разрешения перегрузки нужно сделать максимально декларативно, в плоть до того, чтобы по нему можно было бы сгенерировать спецификацию языка.

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

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

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

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

Ты же предлагаешь революцию сверху. А они практически все обречены на провал.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Expression Tree для описания алгоритмов
От: batu Украина  
Дата: 20.05.10 18:29
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:


VD>>>Документы да еще и "В частности с буквами." — это коечно здорово. Только вот есть два вопроса которые надо решить.

VD>>>1. Нужно ли это хоть кому-то кроме тебя?
B>>Вот тебе нужно.

VD>Мне? Мне не нужна Лада или что там еще? Мне нужна поддержка пролого-подобного языка в Немерле (или дотнете). Мне нужно чтобы я мог в своей программе на Немерле воспользоваться мощью логического программирования для решения определенных задач. Например, для реализации того же вывода типов в самом же Немерле. Сейчас для этого используется специализированный код, но можно было бы использовать и универсальный.


VD>На мой взгляд — это приведет к тому, что язык станет удобнее, гибче, быстрее и надежнее. А именно это и хотят большинство пользователей. Это эволюция. Или революция снизу.


VD>Ты же предлагаешь революцию сверху. А они практически все обречены на провал.

Извини, я много удалил из твоего. Комментировать ничего не буду. Технологии Net тупиковые. Ну, тоже не поверишь. Там теоретически не возможно сделать то, что нужно очень многим. И тебе в частности.
Жаль, что кроме цвета и шрифтов (а это я вообще убрал) никто ничего нового не обнаружил. А там много чего есть принципиально нового и перспективого. Ты не удивился что я практически не отвечал на обсуждение моего языка? Дело в том, что этот материал разместил не я. Я вообще об этом не знал. Ну, и там старая версия обсуждалась. Мне уже позже сообщили. Но пароль дали. А ник мой. Так что я не напрягаюсь пока. Просто интересно пообщаться с тобой и еще есть грамотные. А я не обижаюсь. Если помнишь я предложил пообщаться. Только при общении станет понятна другая точка зрения. Если интересно, то я расскажу почему не возможно втулить логическое программирование. Или почему принципиально невозможно сделать электронный документооборот. С глобализацией данных проблемы возникнут.. Ну, и еще много чего.. Только не считай собеседника конченым тупицей Если хочешь пообщаемся.. Был бы рад если бы ты первые три раздела моего опуса прочитал внимательно. А если не интересно, то желаю удачи в любом случае. Жизнь длинная.. и мало ли что нас ждет впереди.
Re[19]: Expression Tree для описания алгоритмов
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.10 20:09
Оценка: +1
Здравствуйте, batu, Вы писали:

B>Извини, я много удалил из твоего. Комментировать ничего не буду.


Ничего страшно. Только не обижайся, плиз. Я высказал, возможно непрямое, но честное мнение.

B>Технологии Net тупиковые. Ну, тоже не поверишь. Там теоретически не возможно сделать то, что нужно очень многим. И тебе в частности.


Что дотнет, что ява — это конечно не идеал. Там много косяков и много чего не сделано. Но лучшего просто пока что не изобретено. Главное что они обеспечивают приемлемого качества рантйм и экономят создателям компиляторов море времени. Кроме того это популярные платыформы с огромным числом качественных библиотек. Это позволяет создавать реальные прикладные решения здесь и сейчас.

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

Писать аналогичную миртуальную машину с нуля самому — это вообще означает никогда в жизни не получить качественного результата.

Так что это конечно компромисс, но лучшего решения просто нет.

B>Жаль, что кроме цвета и шрифтов (а это я вообще убрал) никто ничего нового не обнаружил.


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

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

B>А там много чего есть принципиально нового и перспективого. Ты не удивился что я практически не отвечал на обсуждение моего языка? Дело в том, что этот материал разместил не я. Я вообще об этом не знал. Ну, и там старая версия обсуждалась. Мне уже позже сообщили. Но пароль дали. А ник мой. Так что я не напрягаюсь пока. Просто интересно пообщаться с тобой и еще есть грамотные. А я не обижаюсь. Если помнишь я предложил пообщаться. Только при общении станет понятна другая точка зрения.


Согласен. Кстати тебе стоило бы попробовать изложить основу идеологии своего языка, а не выкатывать подробный документ. (он все равно не достаточно подробен). Объяснить почему то-то и тот-то приемущество, почему нет этого и этого.

B>Если интересно, то я расскажу почему не возможно втулить логическое программирование.


Интересно, рассказывай.

B>Или почему принципиально невозможно сделать электронный документооборот.


Еще было бы интересно понять зачем этот "электронный документооборот" вообще нужен 99% программистов не занимающихся этой проблематикой.

B>С глобализацией данных проблемы возникнут.. Ну, и еще много чего.. Только не считай собеседника конченым тупицей Если хочешь пообщаемся.. Был бы рад если бы ты первые три раздела моего опуса прочитал внимательно. А если не интересно, то желаю удачи в любом случае. Жизнь длинная.. и мало ли что нас ждет впереди.


Проблема в том, что мой список чтения уже привыкает объем который я могу прочесть за год. Чтобы читать что-то по второму разу мне нужен стимул. Таким стимулом мог бы стать "краткий курс партии" описывающий иделогию языка, его главные фишки, целевую аудиторию и т.п. Но сжато, чтобы это уместилось в одно сообщение. Тогда может быть и не только я прочту и возможно даже изменю свое мнение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Expression Tree для описания алгоритмов
От: Тролль зеленый и толстый  
Дата: 20.05.10 21:41
Оценка:
G>Если ты еще не понял: сама по себе индукция применяется именно там где есть рекурсия, иначе это не индукция получается.

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

Не знаю, как ты собираешься выражать F(n+1) через F(n), если F(n) — это логическое высказывание об n-ном элементе множества. Ты, наверно, имел в виду выражение элемента n+1 через элемент n, но что это дает для доказательства импликации F(n) -> F(n+1)?

Допустим, в Википедии есть пример доказательства по индукции. Где там выражение F(n+1) через F(n)?
Re[20]: Expression Tree для описания алгоритмов
От: batu Украина  
Дата: 21.05.10 05:27
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Ничего страшно. Только не обижайся, плиз. Я высказал, возможно непрямое, но честное мнение.

Та не вопрос. Лучше честно. Вранье ж не помогает исправить ошибки и недостатки.


VD>Ну, и главное я не увидел там того что хотел увидить. Например поддержки ФП, без которого, на мой взгляд, современный язык уже просто не мыслим.

Это не столько язык, сколько единые правила и ситаксис для конструирования любого другого языка. Хотя на нем можно и писать. Просто тогда много лишних инструментов. Теперь о ФП. И вообще о функциях. Применение функций отличается только тем, что в ФП не допускается изменение состояния. Потому все внешние переменные у меня необходимо легализовывать (оператор with). Функции без этого оператора и есть удовлетовряющие требованиям ФП. Кроме этого функции в логическом программировании несут свою нагрузку и вызов их в отличие импертивных и фунциональных языков выполняется интерпретатором, а не в руках пользователя. И еще одна парадигма расширенного ООП. Каждый объект (в том числе и функция) имеет кроме функционального или императивного наполнения (реализация) еще и логическое содержание. Т.е. допускает высказывание (в моей терминологии логическую реализацию). Это так называемая двойственная природа объекта.


VD>Согласен. Кстати тебе стоило бы попробовать изложить основу идеологии своего языка, а не выкатывать подробный документ. (он все равно не достаточно подробен). Объяснить почему то-то и тот-то приемущество, почему нет этого и этого.

Я думаю ответом может быть следующий документ здесь

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