Высокий/низкий уровень, ручное/автоматическое управление

← →
euru © (2010-11-25 14:42) [320]

> Mystic © (25.11.10 13:19) [314]

> А чем не устраивают JavaScript, Lisp, Smalltalk?

Тем, что они уже есть. :)

← →
_oxffff (2010-11-25 14:45) [321]

> euru © (24.11.10 15:15) [299]
>
> > _oxffff (24.11.10 13:06) [296]
>
> > 1. При определении U и Z компилятор проверяет набор перегруженных
>
> > операторов. И сообщает об ошибке неоднозначности определения
>
> > U и Z.
>
> Классы U, Z и A<T> определены в библиотеке. Класс U вообще
> может оказаться приватным.
> И что тогда должно разъяснить это сообщение, если программисту
> вообще неизвестно о существовании такого типа U?

Ответит честно, внутренний тип(без раскрытия имени) не поддерживают операцию * для типа Z

← →
_oxffff (2010-11-25 14:48) [322]

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

← →
euru © (2010-11-25 15:06) [323]

> _oxffff (25.11.10 14:45) [321]

> Ответит честно, внутренний тип(без раскрытия имени) не поддерживают
> операцию * для типа Z

Ну, наверно, да. Что-то в таком роде.
Хотя точнее, наверно, так будет: Конфликт между реализацией класса A<Z> и операцией Z.*(U, Z).
Потому что это необязательно может быть из-за внутреннего типа и в Z может быть несколько перезагрузок оператора *.

← →
Mystic © (2010-11-25 17:37) [324]

> Например, в Паскале есть тип file. Это структура или ссылка?

Это приватный тип :)

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

Если в API в записи есть указатель на другую запись, то как без него жить?

> Ответит честно, внутренний тип(без раскрытия имени) не поддерживают
> операцию * для типа Z

В общем ошибка может быть такой: нет перегруженой операции * для типов _____private2345762 и _____private124712345. Имеются следующие кандидаты: <внушительный список>. Вопрос в том, как это поможет программисту без доступа к коду шаблона узнать, как исправить эту ошибку и какой операции не хватает?

← →
_oxffff (2010-11-25 17:47) [325]

> . Вопрос в том, как это поможет программисту без доступа
> к коду шаблона узнать, как исправить эту ошибку и какой
> операции не хватает?

Можно вывести список автовыведенных constraints для данного шаблона с указанием множества допустимых типов(сигнатур) для данной операции с внутреннем типом.

← →
Mystic © (2010-11-25 17:56) [326]

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

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

← →
_oxffff (2010-11-25 18:21) [327]

> Mystic © (25.11.10 17:56) [326]
>
> > Можно вывести список автовыведенных constraints для данного
>
> > шаблона с указанием множества допустимых типов(сигнатур)
>
> > для данной операции с внутреннем типом.
>
>
> С учетом всевозможных приведений типов получим экспоненциальный
> рост возможных вариантов, что может повесить компилятор
> и не помочь никак программисту.

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

← →
euru © (2010-11-25 18:31) [328]

> Mystic © (25.11.10 17:37) [324]

> Это приватный тип :)

Однако это нисколько не мешает работать с ним как с обычным типом.
String в Дельфи тоже, кстати, своего рода приватный тип.

> Если в API в записи есть указатель на другую запись, то
> как без него жить?

Вообще-то имелся в виду вопрос другого рода. Если в языке не поддерживается такое понятие как указатель или ссылка, то можно ли описывать в нём структуры типа связного списка и если можно, то как?

← →
Mystic © (2010-11-25 19:24) [329]

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

Лично меня в C++ уже ужасно напрягает смотреть, почему шаблон не может быть инстанцирован. Даже сейчас мечтаю о том, чтобы можно было, как в Ada, ручками указывать ограничения. А ты предлагаешь что-то еще более сложное. Тогда точно надо будет повеситься :)

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

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

← →
Mystic © (2010-11-25 19:26) [330]

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

Элементарно, смотри Хаскель. Там что-то вроде этого:

data Tree a = Leaf a | Branch (Tree a) (Tree a)

← →
euru © (2010-11-26 10:22) [331]

> Mystic © (25.11.10 19:26) [330]

> Элементарно, смотри Хаскель.

С таким же успехом можно было посоветовать и Лисп. Только вот на вопрос "как это сделать?" такой ответ никак не отвечает.

← →
_oxffff (2010-11-26 10:43) [332]

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

http://www.wikiznanie.ru/ru-wz/index.php/%D0%9A%D0%BE%D0%BC%D0%B1%D0%B8%D0%BD%D0%B0%D1%82%D0%BE%D1%80_%D0%BD%D0%B5%D0%BF%D0%BE%D0%B4%D0%B2%D0%B8%D0%B6%D0%BD%D0%BE%D0%B9_%D1%82%D0%BE%D1%87%D0%BA%D0%B8

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

Один из самых известных (и, вероятно, из самых простых) комбинаторов неподвижной точки в нетипизированном λ-исчислении называется комбинатором Y. Он был разработан Хаскеллом Карри и определяется следующим образом:

Y = λf.(λx.f(xx))(λx.f(xx))
Необходимо отметить, что комбинатор Y предназначен для использования совместно с вычислительной стратегией «вызов по имени», поскольку выражение (Y g) зацикливается для произвольного g в стратегии «вызов по значению».

← →
jack128_ (2010-11-26 11:10) [333]

> С таким же успехом можно было посоветовать и Лисп. Только
> вот на вопрос "как это сделать?" такой ответ никак не отвечает.
>

тебе привели пример как на хаскеле (в котором нет указателей) описать дерево. Это не ответ??

← →
euru © (2010-11-26 13:53) [334]

> jack128_ (26.11.10 11:10) [333]

> тебе привели пример как на хаскеле (в котором нет указателей)
> описать дерево. Это не ответ??

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

1. Есть некий язык программирования. По контексту обсуждения - это императивный язык.

2. Чтобы не возникал вопрос о нужности/ненужности ручного сбора мусора было предложено не вводить в язык оператор new [284] (нет возможности выделять память, соответственно не нужно её освобождать).

3. Чтобы не возникал вопрос о нужности/ненужности оператора new, было предложено все типы в языке представлять как value type [291].

4. Тогда возникают вопросы:
[302] Как реализовать (а не описать) в компиляторе обработку структур вида
TListNode = record data: string; next: TListNode; end;

[309] Как для таких структур компилятор должен обрабатывать выражения
node.next.data := "blablabla"; // вот тут чего должно произойти, если node.next = nil ?
Выделение нового узла или NullReferenceException?

Вот, собственно говоря, и всё.

Соответственно ответ про Хаскель [330] не отвечает на эти вопросы.

← →
jack128_ (2010-11-26 14:29) [335]

> [302] Как реализовать (а не описать) в компиляторе обработку
> структур вида
> TListNode = record
> data: string;
> next: TListNode;
> end;
>
> [309] Как для таких структур компилятор должен обрабатывать
> выражения
> node.next.data := "blablabla"; // вот тут чего должно произойти,
> если node.next = nil ?
> Выделение нового узла или NullReferenceException?

какой такой nil - если у нас только value типы ?

← →
jack128_ (2010-11-26 14:31) [336]

вообще в императивном(читай энергичном) языке иметь только value-типы -это бред. То есть лет 40 назад возможно прокатило бы, а сейчас - не взлетит..

← →
Mystic © (2010-11-26 14:50) [337]

> euru © (26.11.10 13:53) [334]

Что-то тут не так. Имеет место быть попытка разработать язык программирования вообще без кучи в каком бы то ни было виде (явной или неявной)? Но как в этом контексте понимать

> Выделение нового узла или NullReferenceException?

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

Если куча присутствует неявно (со своим GC), то

> [309] Как для таких структур компилятор должен обрабатывать
> выражения

> node.next.data := "blablabla"; // вот тут чего должно произойти, если node.next = nil ?

Тут NullReference.

В данном примере достаточно одного конструктора

constructor TList(ArgData: string); begin Data := ArgData; Next := nil; end;

и потом

Node.Next := TList("blablabla");

В Хаскеле проще, потому что язык функциональный, и изменять переменные нельзя. Почему просто конструируется новый список.

Haskell data List a = Cons a (List a) | Nil

И строим дальше по своему желанию:

x = Cons "blablabla" Nil; y = Cons "test" x; z = Cons "3" (Cons "2" (Cons "1" Nil));

И т. д. и т. п.

← →
euru © (2010-11-26 15:59) [338]

> jack128_ (26.11.10 14:29) [335]

> какой такой nil - если у нас только value типы ?

Это такая константа, означающая неопределённое значение любого value-типа.

← →
euru © (2010-11-26 16:15) [339]

> jack128_ (26.11.10 14:31) [336]

> вообще в императивном(читай энергичном) языке иметь только
> value-типы -это бред. То есть лет 40 назад возможно прокатило
> бы, а сейчас - не взлетит..

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

← →
euru © (2010-11-26 16:43) [340]

> Mystic © (26.11.10 14:50) [337]

> Что-то тут не так. Имеет место быть попытка разработать
> язык программирования вообще без кучи в каком бы то ни было
> виде (явной или неявной)? Но как в этом контексте понимать
>
> > Выделение нового узла или NullReferenceException?
>
> Как компилятор может выделять место в куче, если ее нет?

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

> Тут NullReference.
> В данном примере достаточно одного конструктора

А зачем? Формально ведь node.next уже содержит значение, равное nil (см. [338]). так что можно смело делать присвоение node.next.data := "blablabla";, не опасаясь никаких исключений.

← →
Mystic © (2010-11-26 17:10) [341]

> Данные-то ему нужно же где-то хранить.

Обычно данные в стеке либо в сегменте данных. Куча уже рождает GC.

> так что можно смело делать присвоение node.next.data :=
> "blablabla";, не опасаясь никаких исключений

Для этого надо знать, как создать объект.

← →
euru © (2010-11-26 17:53) [342]

> Mystic © (26.11.10 17:10) [341]

> Обычно данные в стеке либо в сегменте данных.

Не факт, что в исполняемой среде есть стек. Я уже давал ссылку на статью "Правда о значимых типах", но повторю ещё раз. Там более подробно описано, где могут храниться значимые типы.
http://blogs.msdn.com/b/ruericlippert/archive/2010/10/25/the-truth-about-value-types.aspx

> Куча уже рождает GC.

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

> Для этого надо знать, как создать объект.

Зачем? При объявлении переменной компилятор уже знает какого она типа и как её создать. Конструктор нужен не для создания объекта, а для его инициализации. Сам объект создаётся при первом присваивании ему или хотя бы одному из его компонентов какого-либо значения.

← →
euru © (2010-11-29 10:30) [343]

Продолжим?

← →
euru © (2010-11-30 11:25) [344]

А что, данная тема стала неинтересна?

← →
Mystic © (2010-11-30 12:33) [345]

А что тут еще можно сказать? Все уже давно изобретено. Вряд-ли есть какие-нить еще идеи...

← →
_oxffff (2010-11-30 17:24) [346]

> euru © (30.11.10 11:25) [344]
> А что, данная тема стала неинтересна?

Завтра выхожу на работу и продолжу пилить свой язык YAR.
santonov.blogspot.com

← →
_oxffff (2010-11-30 17:30) [347]

> Вряд-ли есть какие-нить еще идеи...

Не все приятные изобретения попадают в mainstream языки.

← →
euru © (2010-11-30 18:33) [348]

> Mystic © (30.11.10 12:33) [345]

> А что тут еще можно сказать? Все уже давно изобретено. Вряд-
> ли есть какие-нить еще идеи...

Однако же новые языки всё появляются и появляются.

Идеи есть. Например, как я уже предлагал выше, отказаться от ссылочных типов и указателей и оставить только значимые типы. Ещё, например, идея отказаться от var-параметров в подпрограммах.

Собственно, хотелось бы пообсуждать, почему и чем те или иные идеи полезны/бесполезны/бестолковы и т.д.

> отказаться от ссылочных типов и указателей и оставить только
> значимые типы.

Это лютый ахтунг при наличии mutable значений.

Но такой подход уже ровесник Октябрьской Революции в кошерных функциональных языках без побочных эффектов.

← →
_oxffff (2010-11-30 22:04) [350]

Тогда сюда
http://fprog.ru/2010/issue6/

← →
_oxffff (2010-11-30 22:25) [351]

Дальше сюда
http://metacomputation-ru.blogspot.com/
И далее приятного мозголомства ....

> Однако же новые языки всё появляются и появляются.

А что в них принципиально нового? Помнится только Nemerle с его системой макросов. Но по сути похожее было в TeX.

> Идеи есть. Например, как я уже предлагал выше, отказаться
> от ссылочных типов и указателей и оставить только значимые
> типы. Ещё, например, идея отказаться от var-параметров в
> подпрограммах.

Это трудно назвать "новой идеей", потому что до того, как фича была придумана, ее не было. Ну так можно взять любой язык и отказаться в нем от много-чего. Только что это даст? В конце-концов, никто не мешает не пользоваться var-параметрами и указателями :)

> Собственно, хотелось бы пообсуждать, почему и чем те или
> иные идеи полезны/бесполезны/бестолковы и т.д.

Проще по одной идее на тему. Из того, что пришло в голову, список примерно такой:

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

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

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

> euru © (30.11.10 18:33) [348]
>
> > Mystic © (30.11.10 12:33) [345]
>
> > А что тут еще можно сказать? Все уже давно изобретено.
> Вряд-
> > ли есть какие-нить еще идеи...
>
> Однако же новые языки всё появляются и появляются.
>
> Идеи есть. Например, как я уже предлагал выше, отказаться
> от ссылочных типов и указателей и оставить только значимые
> типы. Ещё, например, идея отказаться от var-параметров в
> подпрограммах.
>
> Собственно, хотелось бы пообсуждать, почему и чем те или
> иные идеи полезны/бесполезны/бестолковы и т.д.

Собственно я за обсуждение. Только обсуждение должно быть предметным.
Например описать операционную семантику данного языка.
Были попытки о DiamondShark, но не полные.
Более того вполне возможно если такая семантика будет представлена и более менее доказана и обсуждена нами, то мы бы могли попробовать совместными усилиями реализовать ее в виде языка. Почему нет? :)

← →
Wogn (2010-12-01 16:44) [354]

О, Господи, они собираются убирать ссылочные типы из языка, когда давно уже для защиты от null pointer exception существует Maybe паттерн.
Сборка мусора им не нравится? Правильно, долой сборку мусора, а вместо кучи будем базу данных использовать, SQL же вообще прекрасны образчик языка без явного управления памятью.
А YAR, ну это надо же взять синтаксис Паскаля за основу. Это покрытое пылью и плесенью наследие веков. Это надо "Паскаль с плюшечками" назвать.
Весело, черт побери.

> Mystic © (01.12.10 12:05) [352]

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

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

> oxffff © (01.12.10 15:18) [353]

> Собственно я за обсуждение. Только обсуждение должно быть
> предметным. Например описать операционную семантику данного
> языка. Были попытки о DiamondShark, но не полные.Более того
> вполне возможно если такая семантика будет представлена
> и более менее доказана и обсуждена нами, то мы бы могли
> попробовать совместными усилиями реализовать ее в виде языка.
> Почему нет? :)

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

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

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

> Wogn (01.12.10 16:44) [354]

> О, Господи, они собираются убирать ссылочные типы из языка,
> когда давно уже для защиты от null pointer exception существует
> Maybe паттерн.

А зачем вводить паттерн для защиты от null, если можно в принципе отказаться от такой ситуации?

> euru © (02.12.10 02:15) [356]
>
> > oxffff © (01.12.10 15:18) [353]
>
> > Собственно я за обсуждение. Только обсуждение должно быть
>
> > предметным. Например описать операционную семантику данного
>
> > языка. Были попытки о DiamondShark, но не полные.Более
> того
> > вполне возможно если такая семантика будет представлена
>
> > и более менее доказана и обсуждена нами, то мы бы могли
>
> > попробовать совместными усилиями реализовать ее в виде
> языка.
> > Почему нет? :)
>
> Скорее всего, такой подход ни к чему хорошему не приведёт.
> Потому что желающих заниматься разработкой языка и тем
> более его реализацией окажется слишком мало. А среди тех,
> кто всё-таки решится на это, наверняка будут разные взгляды,
> как должен выглядеть этот язык.
>
> По-моему, лучше как раз обсуждать некоторые идеи. Попытаться
> понять, можно ли эти идеи реализовать. И если невозможно,
> то почему.
>
> Мне вот, например, до сих пор непонятно, почему нельзя в
> нефункциональном языке остановиться только на значимых типах,
> не воодя ссылок и указателей

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

← →
Wogn (2010-12-02 09:38) [359]

>euru © (02.12.10 02:17) [357]

>А зачем вводить паттерн для защиты от null, если можно в принципе отказаться от такой ситуации?

В противном случае, вы получите еще один SQL. Ну или Haskell, если постараетесь. Просто потому, что операции работы с памятью естественны для императивного подхода. Убрав их, вы сделаете императивный язык противоестественным.
А что до ссылок, то паттерн Maybe может быть просто встроенным в язык. Все ссылки - это ссылки Maybe, и программист просто будет вынужден всегда их обрабатывать.

> oxffff © (02.12.10 09:23) [358]

> Рассуждать о сферическом коне в вакууме сложно. Это действительно
> сложно. "нестыковки" могут быть выявлены только на практике.

Хорошо. Попробуем пойти этим путём. Жду описания операционной семантики языка.

Высокий/низкий уровень, ручное/автоматическое управление Найти похожие ветки