Свой компилятор(С++'о подобный)

[pu4koff]

Сообщение от Пепел Феникса

по вашему автоматическая подготовка модуля к выполнению это ошибка?
это вместо ручного вызова Module_Init .

Это всё зависит от планируемой идеологии языка. Для Си-плас-плас и аналогов это не айс, потому как непонятно когда именно вызовется эта самая инициализация и когда выгрузка ресурсов. Для какого-нибудь языка со сборщиком мусора освобождение ресурсов - это не так критично и Finalization не так убого будет выглядеть. Косяк Initialization в том, что работоспособность в некоторых случаях (если там какая-то работа с файлами, сетью,...) будет зависеть от порядка подключения модулей.
Организацию модулей программы в плюсах я бы вообще не рассматривал, т.к. её там нет. Есть отдельные срр файлы, которые друг с другом вообще никак не связаны и больше ничего. Основную работу, как я понимаю, выполняет линковщик и ему это, наверно, не очень легко

[Utkin]

Ленивые вычисления плохо сочетаются с побочными эффектами функций.

Не совсем представляю как это. Приведите пример из реальной жизни.

[Пепел Феникса]

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

я знаю что это не совсем корректный пример, но пример.

Косяк Initialization в том, что работоспособность в некоторых случаях (если там какая-то работа с файлами, сетью,...) будет зависеть от порядка подключения модулей.

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

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

финализация модулей по большей части нужна ради действий перед завершением приложений, ибо утечки ресурсов не будет.(хотя не во всех ОС это справедливо пожалуй)

ну и думаю необходимо добавить возможность написание документации в коде(как в шарпе)

[anyx]

Сообщение от Пепел Феникса

автоматическое задание типа переменной по её значению?
var в C#, auto в C++.0x

Не обязательно было перечислять, я знаю все эти языки...

Я говорю об автоматическом выводе типа вообще всего, для чего это возможно. Я хочу описывать функцию как foo(b, ts, es), а не как foo(b: bool; ts, es: String). И если я потом эту функцию использую как foo(x == y, "equals", "not equals"), то компилятор сам выведет тип аргументов функции, а из этого и тип результата. Фактически, тип нужно будет указывать только у public-функций модуля и у public- и protected-методов public-классов модуля.

Сообщение от Utkin

Не совсем представляю как это. Приведите пример из реальной жизни.

main() =
{
    f = File("ololo.txt");
    a = f.read(1); // Здесь мы не вычисляем значение,
    b = f.read(1); // т.к. оно нам пока не нужно
    print(b + a); // Здесь отложенные вычисления нужно произвести
    // Сначала a, потом b (по порядку в списке аргументов оператора +)
}

В приведённом примере на некоем абстрактном ЯП два байта будут записаны в переменные a и b в обратном (!) порядке, чем мы ожидаем, ведь сначала будет вычисляться значение второго аргумента оператора +. Если бы вместо сложения был бы некоммутативный оператор (порядок операндов имеет значение), то результат бы отличался от ожидаемого. А виной всему нечистота функции File::read, имеющей побочные эффекты.

[Utkin]

anyx, Вы, как мне кажется перепутали немного. В вашем примере все должно вычисляться. Мне известны два варианта организации ленивых вычислений - это неявная обработка параметров функций и явно откладывание вычислений. Явное откладывание реализовано в Scheme - там есть два оператора, один "замораживает" вычисление, до тех пор пока это не потребует другой оператор, который заставляет немедленно вычислить выражение в данной точке. Все явно и ответственность за косяки лежит на программисте. В первом же случае входящий параметр не вычисляется в момент входа в функцию. Например

функция (х, у) - В данный момент значения и первого и второго параметра неизвестны  
(
     Введем переменную а=10 - В данный момент значения и первого и второго параметра неизвестны  
     а = х+5 - Здесь вычисляется х, затем вычисляется а. У не известен
     а = а/у - Здесь вычисляется у, затем вычисляется а
)

Как видите все тривиально и противоречия не возникают. Если вызвать функцию, например как функция (10, 4-6*2), то второй параметр будет вычислен только в строке:

а=а/4-6*2

[Пепел Феникса]

Я говорю об автоматическом выводе типа вообще всего, для чего это возможно. Я хочу описывать функцию как foo(b, ts, es), а не как foo(b: bool; ts, es: String). И если я потом эту функцию использую как foo(x == y, "equals", "not equals"), то компилятор сам выведет тип аргументов функции, а из этого и тип результата. Фактически, тип нужно будет указывать только у public-функций модуля и у public- и protected-методов public-классов модуля.

это практически шаблоны С++.

В приведённом примере на некоем абстрактном ЯП два байта будут записаны в переменные a и b в обратном (!) порядке, чем мы ожидаем, ведь сначала будет вычисляться значение второго аргумента оператора +. Если бы вместо сложения был бы некоммутативный оператор (порядок операндов имеет значение), то результат бы отличался от ожидаемого. А виной всему нечистота функции File::read, имеющей побочные эффекты.

добавить компилю чуть ума и все норм.

[anyx]

Сообщение от Пепел Феникса

это практически шаблоны С++.

ЧТО? Ничего общего. Шаблоны - способ реализации обобщённого программирования, с автоматическим выводом типов не имеет вообще ничего общего. Вы меня плохо поняли, перечитайте посты.

Сообщение от Utkin

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

В Haskell это происходит автоматически и прозрачно для программиста. Я имел ввиду, естественно, именно это. Естественно, компилятор должен сам за всем следить

[Utkin]

В Haskell это происходит автоматически и прозрачно для программиста. Я имел ввиду, естественно, именно это. Естественно, компилятор должен сам за всем следить

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

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

[Пепел Феникса]

ЧТО? Ничего общего. Шаблоны - способ реализации обобщённого программирования, с автоматическим выводом типов не имеет вообще ничего общего. Вы меня плохо поняли, перечитайте посты.

вы имеете в виду чтоб компилятор по коду функции(и вызову при необходимости) вывел типы функций при компиляции?

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

[Utkin]

вы имеете в виду чтоб компилятор по коду функции(и вызову при необходимости) вывел типы функций при компиляции?

Что значит при компиляции? В тот момент как Вы закончили её писать .

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

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

Ну дык функции внутри функций и в си можно объявлять.

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