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

[Сtrl]

Вот такой можно еще синтаксический сахар:

while (...)
{ ... }
else
{ ... }

Ветвь else выполняется, если цикл не выполнился ни разу.

[Utkin]

Синтаксические замены? Ленивые вычисления? Последнее конечно сложновато для компиляторов, но все же. В конце концов все эти лиспы, Scheme и Haskell получили полноценные компиляторы и трансляторы в С.

[pu4koff]

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

тем что у них есть Initialization и Finalization секции

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

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

, плюс ещё куча всяких мелочей и нюансов.

Если не совсем забыл делфи, то там uses из интерфейсного раздела как бы наследуются.
Допустим, есть три модуля a,b и c.
в b написано uses a.
в c написано uses b, но про а ничего не написано. При этом модуль этот виден, т.к. он используется в b. Поправьте, если это я нафантазировал, ибо давненько я код на этом языке не писал

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

очевидно, это в 10 раз удобнее, чем тупые инклуды

Не так уж чтобы и в 10 раз... Просто сложно быть хуже банальной вставки содержимого указанного файла вместо строки #include ...

[Kostia]

Не знаю кто как, но я в php частенько пользуюсь подобным:
file.php:

<?
class MyModule extends Module{
//...
}
return new MyModule(...);
?>
core.php
<?
class Core{
  function CollectModules(){
    mod = include("file.php");
  }
}
?>

Да, да! Я быдло php кодер...

while (...)
{ ... }
else
{ ... }

Тоже и для for'а было бы не плохо

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

Чем оно принципиально отличается от инклюдов?

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

Тогда уж пусть будет всё и всегда виртуальным, для избежания путаницы.

в какой то мере так и будет, но про final помним.(искл, оптимизация итогового бинарника)

Вот такой можно еще синтаксический сахар:

интересная вещь, в принципе реализуется не сложно, но главное не перепуть где чей else.

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

ну это зависит от программиста, но например jpeg использует эти секции для регистрации класса TJPEGImage для TPicture.LoadFromFile.

Если не совсем забыл делфи, то там uses из интерфейсного раздела как бы наследуются.
Допустим, есть три модуля a,b и c.

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

Не знаю кто как, но я в php частенько пользуюсь подобным:

я немного не понял этого...

PS: повторю еще раз, что занимаюсь в свободное время.

[anyx]

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

Вот такой можно еще синтаксический сахар:

while (...)
{ ... }
else
{ ... }

Ветвь else выполняется, если цикл не выполнился ни разу.

В Python'е ветвь else цикла выполняется, если выход из цикла был не по break'у, а нормальный (конец последовательности в for'е, ложность условия в while'е). Хотя и такой , и ваш варианты я не приветствую. По-моему оно делает код нечитабельным.

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

как в делфи uses.

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

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

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

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

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

Согласитесь, это похоже не решение многих реальных задач? Было бы удобно, если бы язык давал возможность безболезненно писать подобные вещи. Например, так:

foo(x, y, z) = a * b * c // Разбиваем задачу на подзадачи
    where
        a = very_long_calculation(x, y) // Решаем каждую
        b = very_long_calculation(z, y) // подзадачу отдельно
        c = very_long_calculation(x, z)

Конечно, в типичных ЯП (С++) такой подход итак применяется, но он не структурирован. Т.е. в одном пространстве имён десятки переменных, и не всегда понятно, для чего они нужны. Тем более там они объявляются до использования, а тут описаны после. А иногда, читая программу сверху вниз, удобно сначала видеть решение большой задачи, а потом уже решение подзадач.

И да, если выберите мой способ, то придётся дать возможность объявлять функции не только в корне файла, но и внутри функций (в примере вместо переменных a, b и c в блоке where вполне могли быть объявлены и функции)

[Utkin]

Конечно, в типичных ЯП (С++) такой подход итак применяется, но он не структурирован. Т.е. в одном пространстве имён десятки переменных, и не всегда понятно, для чего они нужны. Тем более там они объявляются до использования, а тут описаны после. А иногда, читая программу сверху вниз, удобно сначала видеть решение большой задачи, а потом уже решение подзадач.

И да, если выберите мой способ, то придётся дать возможность объявлять функции не только в корне файла, но и внутри функций (в примере вместо переменных a, b и c в блоке where вполне могли быть объявлены и функции)

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

[the_deer_one]

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

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

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

[anyx]

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

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

Спасибо, я знаю.
Не думаете же вы, что конструкцию where я сам придумал, да ещё и по странному совпадению обозвал тем же словом, что и в Хаскелле?

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

Ленивые вычисления?

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

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

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

Во-первых, не в Си, а в С++, и только последней версии стандарта.
Во-вторых, отсутствие автоматического вывода типов (и, как следствие, необходимость объявлять тип в лямбдах), делает их громоздким и неудобным инструментом (каким, собственно, сам С++ и является)

Кстати, Пепел Феникса, как в вашем языке дела с автоматическим выводом типов? Это слишком полезная вещь, чтобы от неё отказываться.

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

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

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

Я имел ввиду, что import можно будет писать не только в начале файла, но и посреди метода. Тогда внешние имена модуля импортируются в локальное пространство имён, не загрязняя основное.

С++ using.

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

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

Кстати, Пепел Феникса, как в вашем языке дела с автоматическим выводом типов? Это слишком полезная вещь, чтобы от неё отказываться.

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