R3>Ну, таким образом можно отказаться и от "var".

а как тогда понять что это есть объявление переменной?

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

R3>>Ну, таким образом можно отказаться и от "var".
DG>а как тогда понять что это есть объявление переменной?

Объявление в тот момент, когда она первый раз встречается в тексте.

Т.е. new несёт и визуальную помощь — помогает визуально выделить, что вот такая-то переменная теперь вот это вот означает.

Сравни:

Class1 cl = new Class1();
cl.DoWork();
cl = new Class2();
cl.DoWork();

и

cl = Class1();
cl.DoWork();
cl = Class2();
cl.DoWork();

Здравствуйте, Курилка, Вы писали:

Ф>>v = MyClass.Constructor();
Ф>>...
Ф>>v.Destructor();
Ф>>-----------------------
Ф>>никогда не понимал, зачем конструктору и деструктору иметь имя.

К>а Constructor и Destructor — это не имена?
Ф>>Это больше похоже на ключевые слова.
К>
Тем не менее мне эти слова нравятся.

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

S_S>>Главная характеристика хорошего синтаксиса, ИМХО, высокая читабельность текста на нем.
S_S>>Это в этом что ли пункте учтено? : "близость к текстам, которыми обмениваются между собой люди."

DG>то, что ты затронул это ближе к стабильности (контексто-независимости).
DG>без new получается, что выражение F(..) — может быть функцией, а может быть конструктором — в зависимости от контекста.
DG>неудобство такого прыганья критично — если функция и конструктор демонстрируют значительно разное поведение.

DG>но я сейчас считаю, что особой разницы между функцией и конструктором нет с точки зрения вызова, поэтому new можно убрать из-за малой полезности.

В Немерле так и сделано. Особых проблем не замечено. Разве что с КодДомом некоторые проблемы есть, так как без типизации АСТ невозможно сгенерировать КодДом. Но так как в немерле без типизации много чего нельзя отличить, то это не существенно.

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

Здравствуйте, Real 3L0, Вы писали:

R3>Ну, таким образом можно отказаться и от "var".

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

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

Здравствуйте, Курилка, Вы писали:

К>а Constructor и Destructor — это не имена?

А чем это будет отличаться от оператора new/delete?

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

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

FR>Если не бороться со скобками то идеальный синтаксис уже давно изобретен s-выражения и соответственно язык Lisp.

Я бы сказал, что это очень своеобразные идеалы. По сути у Лиспа вообще нет синтаксиса. В нем есть AST. И ты вынужден программировать в AST.

Плюс синтаксис лиспа рассчитан на динамическую типизации. Как только появляются типы, то все становится печальнее.

FR>Другой вариант позволяющий описывать более сложные структуры меньшим количеством скобок — Refal.

А как там это выглядит?

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

DG>примечание: синтаксис трактуется в узком смысле, как способ записи информации в виде текста (последовательности символов)

Ужас! Запутал все к чертовой матери. Зачем вся эти философия?

DG>Что такое информация?

Да вот же она — лошадь — Василий Иванович (с)

информация — сведения об окружающем мире и протекающих в нем процессах, воспринимаемые человеком или специальным устройством.{см.С.И.Ожегов. "Словарь русского языка". Москва. 1990г.).

Какие на фиг графы? Какие на фиг дуги? Информацию можно представлять как угодно и чем угодно. Вот поток битов — это самое что ни на есть привычное представление информации.

А уж для разговора о синтаксисе языков вообще не нужно говорить о информации.

Потом каких языков? Естественных? Языков программирования? Это очень разные вещи.

DG>Задача, проблемы и критерии лучшести синтаксиса

Где ты взял это слово "лучшести"?

DG>Основная задача синтаксиса — представить информационный граф в виде текста.

Синтаксис — это формат строения предложений и словосочетаний. Если говорить о синтаксисе ЯП, то это описание структуры программы, т.е. то как интерпретируются символы (в широком смысле этого слова) в языке.

Опять же. Какой на фиг граф? Зачем загонять себя в какие-то рамки?

DG>Основная проблема синтаксиса — с помощью линейной структуры текста и фиксированного набора символов(термов) передать графовую структуру информации и бесконечный набор термов

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

DG>Критерии лучшего синтаксиса:
DG>компактность,
DG>стабильность(контекстно-независимость),
DG>атомарность изменений,
DG>близость к текстам, которыми обмениваются между собой люди.

Что за "атомарность изменений"? Что меняем и где?

Все критерии сомнительны. Все же хороший синтаксис — это:
1. Субъективный показатель.
2. Нечто большее нежели набор каких-то атрибутов.

Любитель ML-еподобных языков (Хаскель, ОКамл) скажет что лучше синтаксис вызова функций без скобок. Любитель С-подобных языков скажет обратное. И оба они будут правы. Тоже самое будет если сравнить отступный синтаксис и скобочный (Питон и С). Или Лисповый и С-ишный.

DG>Гипотеза: т.к. задача, проблемы и критерии хорошести синтаксиса фиксированные, то и задача выделения лучшего синтаксиса имеет одно решение (или конечный небольшой набор решений).
DG>

Не имеет. Твой фиксированный список — это самообман. Столько людей столько и мнений.

Все что мы можем сделать — это объединиться в некоторый коллектив и выработать для этого коллектива некоторый список синтаксических предпочтений.

DG>Приемы используемые синтаксисом
DG>Для решения своей задачи синтаксис использует определенный набор приемов.

Синтаксис — это не процесс, а декларация. Он не может использовать приемы.

DG>Разрыв в структуре(информация — граф, а текст — линеен(список)) решается как:
DG>а) граф представляется в виде дерева, а остальные связи вводятся маркировкой элементов дерева и "использованием" маркеров

Зачем связи для синтаксиса?

DG>b) дерево записывается с помощью скобочной записи

А почему не отступной? И какими скобками будем пользоваться?
Другими словами мы фанаты Лиспа или С?

DG>Разрыв между конечным числом символов и бесконечностью термов(например, чисел) решается как:
DG>терм кодируется последовательностью символов. конец последовательности помечается спец. символом.

Ужас какой! А зачем все это?

DG>Оба этих приема требуют ввода новых термов (скобки, маркеры, привязка маркера к элементу, "использование" маркера, границы одного терма и т.д.), которых не было в самой информации, что в ряде случаев может приводить к конфликту термов информации с термами синтаксиса.

Ты пытаешься путем философствования изобрести AST? Или это ты в синтаксис хочешь напихать скобок и спец.символов-терминаторов? Что-то я ничего не пойму.

DG>Большая часть дальнейших улучшений синтаксиса сводятся к борьбе со скобочной записью и борьбе с конфликтом между исходными термами и термами синтаксиса.(это в следующий раз)

Абстрактная философия в народе зовущаяся фигней.

DG>продолжение следует...

А может не стоит?

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

R3>>Ну, таким образом можно отказаться и от "var".

DG>а как тогда понять что это есть объявление переменной?


Есть такой ЯП Python. и он работает.

Какой из вариантов лучше? :
1) var v = new MyClass();
2) v = MyClass()

вариант 2 — это на питоне.

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

**

Возможные варианты:
* идеального синтаксиса нет — у каждого он свой. и это индивидуально.
* есть. и это Питон. )) потому что он лаконичный, но не до степени мозголомности K/J/Apl

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


FR>>Если не бороться со скобками то идеальный синтаксис уже давно изобретен s-выражения и соответственно язык Lisp.

VD>Я бы сказал, что это очень своеобразные идеалы. По сути у Лиспа вообще нет синтаксиса. В нем есть AST. И ты вынужден программировать в AST.

Это да, но любителей не останавливает

VD>Плюс синтаксис лиспа рассчитан на динамическую типизации. Как только появляются типы, то все становится печальнее.

Ну тот же QI вполне прилично выглядит, конечно и вывод типов
в этом неплохо помогает.

FR>>Другой вариант позволяющий описывать более сложные структуры меньшим количеством скобок — Refal.

VD>А как там это выглядит?

Примерно так (звездочки комментарии аналогичные //):

  * <Parse e.Arithm-expr>  ==  e.Tree
  * e.Tree  == s.Operation (e.Tree-1) e.Tree-2
  *         == s.Operand
  *         ==  empty

  Parse {
    e.Expr, <Last ('+-') e.Expr()>: e1 s.Op(e2) =
                     s.Op(<Parse e1>) <Parse e2>;
    e.Expr, <Last ('*/') e.Expr()>: e1 s.Op(e2)
          = s.Op(<Parse e1>) <Parse e2>;
     e1'^'e2 = '^'(<Parse e1>) <Parse e2>;
     s.Symb, <Type s.Symb>: 'F's.Symb = s.Symb;
     s.Symb, <Type s.Symb>: 'N's.Symb = s.Symb;
     (e.Expr) = <Parse e.Expr>;
      = ;
     e.Exp = 
        <Prout 'Syntax error.Cannot parse 'e.Exp>
        <BR 'compl=' Fail>;
         };

Дальше смотри тут.

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

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

К>>а Constructor и Destructor — это не имена?

VD>А чем это будет отличаться от оператора new/delete?

VD>Что до имен конструкторов, то в одном правильном языке они имеют имя this. Это очень удобно.

Ты автору этих имён задай вопрос

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

Mna>Возможные варианты:
Mna>* идеального синтаксиса нет — у каждого он свой. и это индивидуально.
Mna>* есть. и это Питон. )) потому что он лаконичный, но не до степени мозголомности K/J/Apl

Я в силу своих возможностей веду исследовательский проект по созданию взаимодействия ("человек" или "компьютер") — ("человек" или "компьютер").
Хотя это, конечно, уровнем повыше, чем присвоение переменных, но вот, через некоторое время мне стали попадаться ситуации, когда "действие", которое должно быть выполнено с объектом, надо указывать в обязательном порядке. Ибо однозначно — неоднозначность.
Т.е. Питон в моём случае — плохой вариант.

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

FR>Ну тот же QI вполне прилично выглядит, конечно и вывод типов
FR>в этом неплохо помогает.

На Немерле похоже?

Здравствуйте, Real 3L0, Вы писали:

R3>На Немерле похоже?

У обоих заимствованный из ML паттерн матчинг

VD>

VD>информация — сведения об окружающем мире и протекающих в нем процессах, воспринимаемые человеком или специальным устройством.{см.С.И.Ожегов. "Словарь русского языка". Москва. 1990г.).

очень наивное неточное определение.

VD>Какие на фиг графы? Какие на фиг дуги? Информацию можно представлять как угодно и чем угодно. Вот поток битов — это самое что ни на есть привычное представление информации.

ага, а число — это поток цифр.

не путай — представление информации, и саму информацию.

VD>А уж для разговора о синтаксисе языков вообще не нужно говорить о информации.

говорить об инструмента, не говоря о цели — это чревато.

VD>Потом каких языков? Естественных? Языков программирования? Это очень разные вещи.

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

DG>>Основная задача синтаксиса — представить информационный граф в виде текста.

VD> то как интерпретируются символы (в широком смысле этого слова) в языке.

вот оно интерпретировалось-интерпретировалось, и что в результате?
а в результате интерпретации сначала строится AST — (и все доп. символы отваливаются — уходят скобки, кавычки, пробелы, сепараторы и т.д.)
а после того как в асте, резолвятся все ссылки — получается граф.
дальше который уже и обрабатывается.

VD>Синтаксис — это формат строения предложений и словосочетаний. Если говорить о синтаксисе ЯП, то это описание структуры программы, т.е.

структуру программы уж точно к синтаксису отношение не имеет.
структура уже определяется моделью языка.

если брать тот же xml — это хорошо видно.
xml описывает лишь кодирование информации с помощью символов (сама структура описывается где-то еще).

VD>Опять же. Какой на фиг граф? Зачем загонять себя в какие-то рамки?

это описание того, с чем приходится иметь дело.
для тебя описание атомов в виде таблицы менделеева тоже лишние рамки, которые мешают свободе творчества?


DG>>Основная проблема синтаксиса — с помощью линейной структуры текста и фиксированного набора символов(термов) передать графовую структуру информации и бесконечный набор термов

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

парсер — это уже инструмент, который работает с данным синтаксисом.

например, xml — это язык, который описывает в первую очередь лишь синтаксическую часть.
и только видов парсеров xml — как грязи: sax, reader, dom

VD>Любитель ML-еподобных языков (Хаскель, ОКамл) скажет что лучше синтаксис вызова функций без скобок. Любитель С-подобных языков скажет обратное. И оба они будут правы. Тоже самое будет если сравнить отступный синтаксис и скобочный (Питон и С). Или Лисповый и С-ишный.

"скобки" всегда есть, если нужно выразить дерево, другое дело что они могут быть завуалированными, как, например, в питоне
в C-ишном синтаксисе — для скобочной записи используются весь спектр скобок: фигурные, круглые, квадратные, угловые.
в паскале — скобочная запись кодируется с begin/end, круглые, прямоугольные
в xml-е — скобки в виде тегов
в питоне — скобки заменяются на отступы
в lisp — только круглые скобки
в ml/haskell — остались только круглые скобки для записи мат. выражений, а деревянная структура программы передается с помощью набора ключевых слов (let, in, if/then и т.д.), т.е. здесь нет фиксирования на уровне синтаксиса единого способа задания дерева (имхо, это неудобно для чтения)


DG>>Разрыв в структуре(информация — граф, а текст — линеен(список)) решается как:
DG>>а) граф представляется в виде дерева, а остальные связи вводятся маркировкой элементов дерева и "использованием" маркеров

VD>Зачем связи для синтаксиса?

синтаксис нужен для передачи связей, а не "связи для синтаксиса"

DG>>продолжение следует...

VD>А может не стоит?

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

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

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

К>>а Constructor и Destructor — это не имена?

VD>А чем это будет отличаться от оператора new/delete?

Внешним видом

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

DG>>>продолжение следует...

VD>>А может не стоит?

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

Не обижайся, но то что ты деалешь — это профанация. К науке это отношения не имеет.

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

Естественно все ИМХО.

VD>Я понимаю, что ты прочел интересную и умну книги и теперь в тебе бьет фонтан энтузиазма.

да-да, я прочел целую одну книгу

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

VD>>Я понимаю, что ты прочел интересную и умну книги и теперь в тебе бьет фонтан энтузиазма.

DG>да-да, я прочел целую одну книгу

Я про последнее время. Видно, что это тебя вдохновило. Но вот идей как-то не видно. Какая-то пустая философия. Читаешь и кроме недоумения (и возможно раздражения) ничего не испытываешь.

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