[C++] Чего вам нехватает в языке?

* устроить

>Когда говорят об операциях над переменными подразумевают операции над переменными.
Так объясните, что такое переменная?

Прости, но меня ломает в два часа ночи читать лекции о том, что значит выражение «а = а + 1». Ты можешь найти абзацы, главы и может быть даже разделы почти в любом самоучителе по программированию.

> Кто-то пишет один DSL для всех возможных применений программирования? Ну-ну, пока что это никому не удалось.

Кстати, насколько нелокальный вывод типов применяется в практическом хаскеле?

ИМХО вывод типов нужен когда мы определяем нечто *формулой*, и дальше наплевать (например, возведение в натуральную степень через умножение); интересно, что возведение в целую степень уже потребует каких-то аксиом (типа а*1/а=1); тут все локально (ограничено 1 функцией, может 2?)

самый нелокальный вывод типов, о котором я могу предположить — это например парсер для грамматики (где все фактически завязано в граф); все ограничено модулем

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

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

какие есть примеры вывода типов, где он ограничен не одной функцией?

>Переменная это синоним значения.

Переменная в ЯП это синоним значения

Да ты продолжаешь меня радовать =). Хрен я тебя в игнор отправлю. Не дождешься :3

Посмотри сколько раз встречается выражение «значение переменной» и подумай, почему это не ниразу не тавтология?

>Да ты продолжаешь меня радовать =). Хрен я тебя в игнор отправлю. Не дождешься :3
Я рад, что ты рад.

Посмотри сколько раз встречается выражение «значение переменной» и подумай, почему это не ниразу не тавтология?

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

Ты меня кстати тоже доставляешь, в виде банного листа ^)

Но когда совершается операция над переменной, то она совершается и над значением которое в ней.

да ну?

(defstruct foo value)
; FOO

(setf x (make-foo :value 1))
;;; операция над переменной -- связывание х с новым значением, операции над значением нет, т.к. x несвязана
; #S(FOO :VALUE 1)

(setf y x)
;;; операции над переменными -- связывание y со значением x
; #S(FOO :VALUE 1)

(setf (foo-value x) 2)
;;; операция над значением, операций над переменной нет
;;; точнее есть -- получение места, но ведь это не одна и та же
;;; операция, что и операция над значением, как ты утверждаешь
; 2

x
; #S(FOO :VALUE 2)

y
; #S(FOO :VALUE 2)

(setf x (make-foo :value 1))
;;; операция над переменной -- связывание x с новым значением
;;; никаких операций над старым значением x не происходит
; #S(FOO :VALUE 1)

y
; #S(FOO :VALUE 2)

Я отвечал вот на это:

Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

И? Какое отношение к этому имеет «предметная область программирования»?

Переменная в ЯП это синоним значения,

Э-э-э... Значение, вообще-то, не меняется. А переменная в мейнстримных языках меняется.

Хотя, конечно, всё потихоньку идёт к лучшему.

Кстати, насколько нелокальный вывод типов применяется в практическом хаскеле?

Не понял, что имеется в виду. Совершенно.

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

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

> Еще желательно чтобы какая-то информация (хотя бы об AST, приоритетах) была доступна (взглядом) даже тому, кто не знает сам DSL

С листа? На бумаге? Или только после часового мышевозюканья поверх кода?

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

Если первое, то тогда никакого DSL и быть не может и не должно.

Опять-таки: библиотека C-шных функций вполне может рассматриваться как некоторого рода DSL. Проблема в том, что такой DSL будет либо немыслимо громоздким, либо чрезвычайно слабеньким.

а вообще это тема отдельного топика

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

Но главное, он будет читабельным и поддерживабельным. И поймет его каждый, кто знает Си.

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

>Но главное, он будет читабельным и поддерживабельным. И поймет его каждый, кто знает Си.

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

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

> дык создавай, обсудим. то, что у тебя написано - не решение

да, создам.

Создавай. Только людям не показывай. А то еще найдутся психи, которые захотят этим воспользоваться.

DSL надо давить и изживать во всех проявлениях.

> DSL надо давить и изживать во всех проявлениях.

Стесняюсь даже спросить о твоем отношении к ф.п. в целом, для которого dsl - вполне обыденное явление.

> Стесняюсь даже спросить о твоем отношении к ф.п. в целом, для которого dsl - вполне обыденное явление.

Я почти ничего не имею против ФП, так как там DSL такие же, как библиотеки в Си. Язык не искажается. Все делается в рамках средств языка.

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

> Я люто, бешенно ненавижу расширяемые языки и DSLи, реализованные в виде отдельных интерпретаторов или компиляторов.

Вы намекаете на CL?

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

Т.е. DSL реализованый на смеси Boost.MPL и Boost.Preprocessor (обе используют только стандартные средства С++) лучше чем отдельный кодогенератор (пусть даже на том же С++ написанный, тогда от читающего не потребуется знания ещё одного языка) вне зависимотсти от читаемости кода кодогенератора и внятности сообщений об ошибках?

>Я люто, бешенно ненавижу расширяемые языки и DSLи, реализованные в виде отдельных интерпретаторов или компиляторов.

Эм... у меня вот есть отличный пример DSL для Си: lex+yacc. Хотите делать парсер на чистом Си? Ну вперед =)

А ты не замечал, что все промышленно применяемые парсеры написаны без всяких там якков. Генераторы парсеров - отстой, вручную закодированные recursive descent парсеры рулят.

Найди хотя бы в том же gcc парсер на yacc, да?

Просто не надо реализовывать DSL в виде какого бы то ни было кодогенератора. Генерация кода - отстой и рассадник багов. DSL вообще не нужны. Нужны библиотеки.

DSL вообще не нужны. Нужны библиотеки.

Конечно, гораздо лучше получить сообщение обшибке на 100500 строк из-за некорректного параметра шаблона, чем краткое сообщение об ошибке в коде на DSL.

Найди хотя бы в том же gcc парсер на yacc, да?

при этом генерация кодогенератора там используется, что несколько ослабляет твою позицию

Генераторы парсеров - отстой, вручную закодированные recursive descent парсеры рулят.

См., например, ANTLR и код, который он генерирует.

Генерация кода - отстой и рассадник багов.

О да, конечно, в

  (with-open-file (foo "file.txt")
    (my-very-cool-function foo))

намного легче сделать ошибку, чем в

 (let ((foo (open "file.txt")))
  (unwind-protect
       (multiple-value-prog1
           (my-very-cool-function foo)
         (when foo (close foo)))
    (when foo (close foo :abort t))))

Чего еще раскажешь?

>но некоторые до сих пор думают, что С++ - единственная альтернатива в плане производительности

А какие есть еще альтернативы?

А какие есть еще альтернативы?

си + обвязка на высокоуровневых языках, например.

>си + обвязка на высокоуровневых языках, например.
Чем лучше C++ + обвязка? Особенно если учесть наличие в С++ структур данных вроде vector, map и т. п. Самому их реализовать не трудно, конечно, но зачем? И все это оттестировано, без зависимостей от малораспространенных библиотек и т. п.

> Чем лучше C++ + обвязка?

Тем, что FFI для сей есть в любом языке, для c++ - нет.

Особенно если учесть наличие в С++ структур данных вроде vector, map и т. п

Особенно, если учесть, что писать на си++ - мучение, оно того не стоит.

И все это оттестировано, без зависимостей от малораспространенных библиотек и т. п.

Это ты о чем?

>Тем, что FFI для сей есть в любом языке, для c++ - нет.
Но для некоторых есть. Чаще всего этого достаточно.

Особенно, если учесть, что писать на си++ - мучение, оно того не стоит.

Учить все равно придется, а после этого не такое уж и мучение.

Это ты о чем?

О том, что есть в STL, Boost.

Это был мой пост.

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

И мы возвращаемся к моему исходному тезису: язык должен быть таким, чтобы DSL могли ложиться в него, не требуя расширения.

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

Кстати, отличный пример. Есть Yacc - внешний DSL, громоздкий и неудобный. А есть Parsec - EDSL, простой, как тапок, без всяких специальных языковых расширений, существенно более мощный, чем Yacc, ибо сохраняет все возможности языка, в который он встроен.

(with-open-file (foo "file.txt") 
    (my-very-cool-function foo)) 

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

withOpenFile :: String -> (File -> a) -> Maybe a
...
withOpenFile "file.txt" $ \foo -> myVeryCoolFunction foo

> >> Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

И? Какое отношение к этому имеет «предметная область программирования»?

А DSL'и никак не связаны с предметной областью?

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

Там обычно не просто вызов одной функции, а целая implicit porgn форма, в которой могут использоваться «нелокальные» для нее переменные, так что сделать с помощью hof в CL не получится.

Кстати, в варианте хаскеля учтено, что эта функция может делать совершенно всякие гадкие побочные (IO и не только) эффекты?

О том, что есть в STL

в STL очень мало что есть

Boost

а половина Boost решает проблемы C++, а не предметной области

мб так?:

(defun with-open-file-fn (filename fn &rest params)
  (let ((foo (apply #'open filename params)))
    (unwind-protect
      (multiple-value-prog1
          (funcall fn foo)
        (when foo (close foo)))
      (when foo (close foo :abort t)))))

(with-open-file-fn "file"
    #'(lambda (foo)
        (my-very-cool-function foo)))

А DSL'и никак не связаны с предметной областью?

Связаны. А при чём тут «предметная область программирования»?

Там обычно не просто вызов одной функции, а целая implicit porgn форма, в которой могут использоваться «нелокальные» для нее переменные, так что сделать с помощью hof в CL не получится.

Не понял. Можно пример?

Кстати, в варианте хаскеля учтено, что эта функция может делать совершенно всякие гадкие побочные (IO и не только) эффекты?

Упс.

withOpenFile :: String -> (File -> a) -> IO a 
... 
  result <- withOpenFile "file.txt" $ \foo -> myVeryCoolFunction foo 

Не понял. Можно пример?

(let ((count 0))
  (defun foo ()
    (with-open-file (s *file* :direction :output :if-exists :supersede)
      (format s "~a~%" (incf count)))))

Каждый раз, когда запускается функция, она записывает количество своих запусков в файл file. СОбственно не суть, важно то, что нам нужно использовать переменную из лексического окружения, т.е. «функция» my-very-cool-function реально можеть принимать не один аргумент, а сколько угодно. Даже если бы в лиспе легко делалось partial application, это все-равно не сгодилось - мы бы получили намного менее нечитаемый вариант вроде такого

(let ((count 1))
   (defun foo ()
     (with-open-file-fn (*file* (curry
                                 (lambda (count s)
                                   (format s "~a~%" count)) count)
                                :direction :output :if-exists :supersede))
     (incf count)))

На хаскелле, как я пониимаю, тоже придется повторять несколько раз все параметры.

При том, что получаемые DSL'и в теории должны одинаково хорошо подходить как для управления кассой с полумегабайтом памяти, последовательной линией связи, лсд-экранчиком в 60*3 и устройством печати, так и для моделирования физпроцессов теплообмена в газовых турбинах, xslt-преобразований, пакмана/тетриса для мобильного телефона или флэш-игры.

Ничего не смущает в этом, далеко не полном, перечне?

>При том, что получаемые DSL'и в теории должны одинаково хорошо подходить как для управления кассой с полумегабайтом памяти, последовательной линией связи, лсд-экранчиком в 60*3 и устройством печати, так и для моделирования физпроцессов теплообмена в газовых турбинах, xslt-преобразований, пакмана/тетриса для мобильного телефона или флэш-игры.

Меня вот смущает твой бессвязный ответ.

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

И в чём проблема??? У нас нет замыканий?