Oberon space
General Category => Общий раздел => Тема начата: Vartovyj от Декабрь 29, 2011, 11:46:49 am
-
Что бы вы поменяли в Обероне?
Скажем, можно было бы избавиться от громоздких конструкций: ARRAY N OF, POINTER TO
VAR a: ARRAY N OF REAL | VAR a[N]:REAL | a[N]:REAL (*убрать VAR из языка вообще*)
TYPE Node = POINTER TO NodeDescriptor | TYPE Node = ^NodeDescriptor
n:=n+1 | n+=1
b:=b+c | b+=c
Убрать BEGIN - автоматическое распознавание границы между определением и телом функций, модулей.
-
Не касаясь целесообразности подобного расширения, скажу, что вроде бы грамматику ввод упрощенного синтаксиса не усложнит. То есть форма VAR a[N]:REAL не делает грамматику Оберона сложнее чем LL(1) (а она и так LL(1)).
В плане добавления в синтаксис - я бы добавил инициализаторы массивов констант. Ибо дюже неудобно руками через arr[1]:=value забивать 223 коэффициента например fir-фильтра (и да, эти коэффициенты - константа, они НИКОГДА не меняются, поэтому класть их в нечто мутабельное, вроде массивов в обероне, смысла не имеет. это менее эффективно и более подвержено ошибкам).
-
В плане добавления в синтаксис - я бы добавил инициализаторы массивов констант. Ибо дюже неудобно руками через arr[1]:=value забивать 223 коэффициента например fir-фильтра (и да, эти коэффициенты - константа, они НИКОГДА не меняются, поэтому класть их в нечто мутабельное, вроде массивов в обероне, смысла не имеет.
CONST arr[223] = 65,73,3,821,...,105
CONST arr[] = 65,73,3,821,...,105
-
VAR a[N]:REAL
Думаю, a :[N] REAL по-лучше будет.
-
CONST arr[223] = 65,73,3,821,...,105
CONST arr[] = 65,73,3,821,...,105
С одной стороны, в массив могут сложить указатели на записи, значит arr[223] = ... не очень-то поиспользуешь. Только исключительно для простых типов.
С другой стороны, сделали же в КП для строк исключение (сравнение и присваивание без необходимости явно обращаться к каждой ячейке массива...
-
CONST arr[223] = 65,73,3,821,...,105
CONST arr[] = 65,73,3,821,...,105
С одной стороны, в массив могут сложить указатели на записи, значит arr[223] = ... не очень-то поиспользуешь. Только исключительно для простых типов.
С другой стороны, сделали же в КП для строк исключение (сравнение и присваивание без необходимости явно обращаться к каждой ячейке массива...
По большому счету нужна возможность инициаизации (а для констант - объявления) всех базовых структур данных: простых типов, массивов, структур. В том числе рекурсивно.
-
Пояюсню: очень хорошо когда в языке общего назначения есть подъязык описания данных. Как например в js (несмотря на его общую говенную сущность) есть такой подъязык и это очень удобно. Настолько удобно, что его выдернули и оформили отдельно, чтобы был доступен всем другим: json (http://json.org/json-ru.html).
И очень неприятно когда такого языка нет. Кстати, до недавних пор такого полноценного языка небыло и в C и C++. Теперь есть.
-
И очень неприятно когда такого языка нет. Кстати, до недавних пор такого полноценного языка небыло и в C и C++. Теперь есть.
Что есть?
-
Есть например это: http://ru.wikipedia.org/wiki/C%2B%2B0x#.D0.A3.D0.BD.D0.B8.D0.B2.D0.B5.D1.80.D1.81.D0.B0.D0.BB.D1.8C.D0.BD.D0.B0.D1.8F_.D0.B8.D0.BD.D0.B8.D1.86.D0.B8.D0.B0.D0.BB.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D1.8F
То есть теперь в С++ можно единообразно инициализировать в том числе и сложные пользовательские типы данных. Раньше вот это можно было лишь для простых структур, без конструкторов:
struct B {double r; double im;};
struct A {
int arr[3];
char c;
B b;
};
int main() {
A a = {{1,2,3}, 'a', {-1.0,1.0}};
return 0;
}
А например в C89 вот так было нельзя написать:
typedef struct {double r; double im;} B;
typedef struct {
int arr[3];
char c;
B b;
} A;
int main() {
A a = {{1,2,3}, 'a', {-1.0,1.0}};
return 0;
}
В C99 уже можно. В C11 по моему там еще что-то улучшили в этом направлении.
-
Идея с json хороша, но я предлагаю рассмотреть не универсальное решение для всех языков, а обертку только к Оберонам.
Кстати, коменты я бы взял C-подобные, тоесть /*...*/ и //, так как виртовские (*...*) зрительно интерферируют с процедурными скобками.
Тут в одном из топиков жаловались на VAR и засилие точек с запятой. Так, от VAR-а можно отказаться, просто сделав компилятор более интеллектуальным.
-
Идея с json хороша, но я предлагаю рассмотреть не универсальное решение для всех языков, а обертку только к Оберонам.
Да, про это и говорится - про подъязык описания данных. Если рассматривать грамматику как граф (а она граф и есть), то на нем отчетливо видны подъязыки из которых состоит язык (например Оберон): http://valexey.blogspot.com/2010/05/blog-post.html
-
Если приделать к оберону удобный современный синтаксис, то это уже не будет оберон, и уж оберонщики его точно не признают...
-
Если приделать к оберону удобный современный синтаксис, то это уже не будет оберон, и уж оберонщики его точно не признают...
Даже если просто капс убрать? :-)
На самом деле два вопроса:
1) нужно ли это самое признание оберонщиков?
2) что и зачем мы хотим в итоге получить?
-
Если приделать к оберону удобный современный синтаксис, то это уже не будет оберон, и уж оберонщики его точно не признают...
Даже если просто капс убрать? :-)
Особенно если убрать капс. Ведь ключевые слова в верхнем регистре -- одна из важнейших фишек оберона, которой они всегда аргументируют отсутствие подсветки синтаксиса.
На самом деле два вопроса:
1) нужно ли это самое признание оберонщиков?
Ну если оберонщики не станут признавать этот язык (так же как и Зоннон), то и называть его обероном не следует.
2) что и зачем мы хотим в итоге получить?
Да, кстати, хороший вопрос...
-
Особенно если убрать капс. Ведь ключевые слова в верхнем регистре - одна из важнейших фишек оберона, которой они всегда аргументируют отсутствие подсветки синтаксиса.
А зачем убирать подсветку в современных редакторах? Думаю, правильный вариант - сделать как в Зонноне: или все ключевое слово капсом или все без.
Ну если оберонщики не станут признавать этот язык (так же как и Зоннон), то и называть его обероном не следует.
В Зонноне грубо извратили идею оберона с ооп и с NET, так как Оберон - это сам себе NET.
что и зачем мы хотим в итоге получить?
Эстетически красивый, простой вариант синтаксиса, возможно просто как настройка.
-
А зачем убирать подсветку в современных редакторах?
Чтобы выделять цветом (и шрифтом) что-то другое. Идея утопическая в применении к современному массовому производству, но тем не менее - оберонщики за нее держатся и так просто не откажутся.
-
А зачем убирать подсветку в современных редакторах?
Чтобы выделять цветом (и шрифтом) что-то другое. Идея утопическая в применении к современному массовому производству, но тем не менее - оберонщики за нее держатся и так просто не откажутся.
Да-да, они таким способом выделяют смысловые куски кода...
-
А вот я лично например не очень понимаю зачем нужен капс в ключевых словах и/или подсветка синтаксиса. Это ж до какой степени нужно не знать язык, чтобы требовалось что-то там подсвечивать/выделять капсом?
Единственное что - подсветка чуть-чуть помогает избежать опечаток. Но это должна быть подсветка не просто ключевых слов (в них обычно опечаток нет, а если есть, то они видны сразу), а подсветка более сожных сущностей. Например строковый литералов. Тогда сразу видно что например вместо "foo bar" написал "foo bar'. Или коментариев. Ну и так далее. То есть правильную подсветку должен делать полноценный парсер текста. Причем умный парсер. Никакой капс этого не заменит.
С другой стороны, если у нас есть такой умный парсер, то зачем нам постоянная расцветка синтаксиса? Пусть он лучше ошибки проверяет и подчеркивает неверное красным на лету (или иначе показывает ошибку, но только в том месте где она есть, а не во всем исходнике перманентно).
-
А вот я лично например не очень понимаю зачем нужен капс в ключевых словах и/или подсветка синтаксиса. Это ж до какой степени нужно не знать язык, чтобы требовалось что-то там подсвечивать/выделять капсом?
Единственное что - подсветка чуть-чуть помогает избежать опечаток. Но это должна быть подсветка не просто ключевых слов (в них обычно опечаток нет, а если есть, то они видны сразу), а подсветка более сожных сущностей. Например строковый литералов.
Выделение нужно для быстрого визуального схватывания кода. В современных редакторах лучше это делать изменением шрифта и цвета, естественно автоматически, самим редактором, в процессе написания кода.
-
Выделение нужно для быстрого визуального схватывания кода. В современных редакторах лучше это делать изменением шрифта и цвета, естественно автоматически, самим редактором, в процессе написания кода.
А по моему - не нужно. Спокойно (и довольно много) пишу в nano, и еще больше читаю кода через "cat srcfile | less" без всякой подсветки синтаксиса. Зачем акцентировать мое внимание на ключевых словах? Я ж их и так помню, кроме того - они не важнее других сущностей. Например библиотечных функций высшего порядка (или их эмуляций).
Помню когда писал на java одну относительно сложную вещь, чтобы сосредоточиться отключил в netbeans подсветку синтаксиса вообще. Почему-то подсветка сильно мешала сконцентрироваться на своих абстракциях. А вот с диалектами оберона (Оберон, Оберон-07, Оберон-2, КП) так не получилось бы - там капс ключевых слов зашит в синтаксис языка, и от этого так просто не избавиться.
-
Помню когда писал на java одну относительно сложную вещь, чтобы сосредоточиться отключил в netbeans подсветку синтаксиса вообще. Почему-то подсветка сильно мешала сконцентрироваться на своих абстракциях. А вот с диалектами оберона (Оберон, Оберон-07, Оберон-2, КП) так не получилось бы - там капс ключевых слов зашит в синтаксис языка, и от этого так просто не избавиться.
Все акцентирования должны быть на уровне редактора, а не компилятора - тоесть отключаемые и настраиваемые под себя. Кроме того, такие длинные, громоздкие синтаксические конструкции, как array of integer и тд должны отсутстовать - вот это, в основном, и побудило меня открыть тему.
-
В Зонноне грубо извратили идею оберона с ооп и с NET, так как Оберон - это сам себе NET.
Гм. С этого места по подробнее. Возможно ты немного заблуждаешься :-) Смотри, если мы говорим про язык программирования "Oberon", то там нет (не требуется и не упоминается в спецификации на язык) следующего:
- Сборщика мусора
- Проверки выхода за границы массива
- Проверки арифметического переполнения (еси в байт записать число 340 - что будет?)
- Проверки на деление на нуль (12/0 -- что случится?)
- Метаинформации и методов для получения оной. То есть нет даже рефлекшина.
- Динамической загрузки и выгрузки модулей
- Стандартной библиотеки вообще. То есть даже Hello World не написать так, чтобы он стандартно работал везде
По сути Оберон - это Си, в который добавили одиночное наследование для структур + немного rtti для них (run time type information) + работу с указателями вынесли в отдельный модуль SYSTEM, который нужно явно импортировать + чуть строже работают с типами. Но где тут аналог .net'a?
Эстетически красивый, простой вариант синтаксиса, возможно просто как настройка.
А тут имеем философский вопрос - что останется от Оберона, если у него оторвать синтаксис (оставив, впрочем, например грамматику и семантику)? Останется ли после этого оберон обероном? Потому как на синтаксис Вирт и его приверженцы очень сильно акцентируют внимание.
-
Да, забыл одну штуку - в Обероне, относительно Си, убрали из стандартной библиотеки и зашили в сам язык функцию выделения памяти на куче. Функции освобождения памяти же в Обероне просто нет.
-
Гм. С этого места по подробнее.
Я имел ввиду систему вцелом: КП+ББ или ActiveOberon+BlueBottle.
-
Гм. С этого места по подробнее.
Я имел ввиду систему вцелом: КП+ББ или ActiveOberon+BlueBottle.
Ну, тогда наверно стоило уточнить, что предлагается менять синтаксис не Оберона, а КП. Или Active Oberon'a. Они все же весьма отличаются от оберона как синтаксически, так и семантически.
Вообще, к задаче по экспериментированию с синтаксисом можно подойти с двух сторон:
- Написать препроцессор который будет перегонять с нашего синтаксиса в, скажем, КПшный. Компилировать полученную кашу посредством КП-компилятора.
- Наваять свою реализацию какого-нибудь оберона с оторваным синтаксисом. Затем уже отдельно придумывать к нему разные синтаксисы и парсеры для них.
При должном развитии по первому пути он неизбежно сведется ко второму, просто кодогенерация будет не в байткод llvm или инструкции целевой архитектуры, а в КПшный код.
PS. Я, кстати, слабо себе представляю как в Зонноне можно было что-то извратить, ведь он изначально делался именно под "систему" .net, в отличае от, скажем КП (КП делался под Java, точнее с оглядкой на Java - есть реализация под jvm - gpcp). Только, как оказалось, КП в среду java/jvm интегрируется плохо, поэтому, чтобы второй раз на те же грабли не наступать, Zonnon сильнее отошел от Оберона, чем КП.
Да, а Оберон (и просто и Оберон-2) вполне себе живет вне всяких систем, взять тот же XDS, или oo2c, или Pow!, или, скажем, Astrobe (актуальный и развивающийся коммерческий проект).
-
Ну, тогда наверно стоило уточнить, что предлагается менять синтаксис не Оберона, а КП. Или Active Oberon'a. Они все же весьма отличаются от оберона как синтаксически, так и семантически.
Да, КП, а значит и Оберон, Оберон2.
Вообще, к задаче по экспериментированию с синтаксисом можно подойти с двух сторон:
- Написать препроцессор который будет перегонять с нашего синтаксиса в, скажем, КПшный. Компилировать полученную кашу посредством КП-компилятора.
Вот этот вариант наиболее реален для первичных экспериментов.
PS. Я, кстати, слабо себе представляю как в Зонноне можно было что-то извратить, ведь он изначально делался именно под "систему" .net
Мне просто сам NET не нравится. Сугубо имхо. Оберон я рассматриваю именно как альтернативу NET. В идеале для этого нужно, чтобы были некие общие библиотеки для всех Оберонов + возможно Модулы2, Ады ну и пхп, питон.
Скажем будет: PHP.Oberon, PyOberon:)
-
Ну, тогда наверно стоило уточнить, что предлагается менять синтаксис не Оберона, а КП. Или Active Oberon'a. Они все же весьма отличаются от оберона как синтаксически, так и семантически.
Да, КП, а значит и Оберон, Оберон2.
Ну, если мелкие косметические изменения (очень мелкие), то да. Если же что-то более-менее серьезное, что потребует писать полноценный парсер, то уже сразу нет.
PS. Я, кстати, слабо себе представляю как в Зонноне можно было что-то извратить, ведь он изначально делался именно под "систему" .net
Мне просто сам NET не нравится. Сугубо имхо. Оберон я рассматриваю именно как альтернативу NET. В идеале для этого нужно, чтобы были некие общие библиотеки для всех Оберонов + возможно Модулы2, Ады ну и пхп, питон.
Скажем будет: PHP.Oberon, PyOberon:)
А чем .net не нравится? Ну, то есть я совсем не фанат .net'a, но и не стремлюсь ему аналоги создавать :-)
Также не очень понятно как свести к общему знаменателю Аду и Оберон - скажем в Аде есть generic-модули, в Обероне обобщенки нет вообще. Более того, чтобы скажем в ББ полноценно присутствовал и Оберон и КП, оный ББ придется переписать на их общем знаменателе - Обероне.
-
С другой стороны, если у нас есть такой умный парсер, то зачем нам постоянная расцветка синтаксиса? Пусть он лучше ошибки проверяет и подчеркивает неверное красным на лету (или иначе показывает ошибку, но только в том месте где она есть, а не во всем исходнике перманентно).
Вы разве забыли главный принцип оберона?
"Инструмент не должен быть умнее своего пользователя!!!111"
-
Единственное что - подсветка чуть-чуть помогает избежать опечаток. Но это должна быть подсветка не просто ключевых слов (в них обычно опечаток нет, а если есть, то они видны сразу), а подсветка более сожных сущностей. Например строковый литералов. Тогда сразу видно что например вместо "foo bar" написал "foo bar'. Или коментариев. Ну и так далее. То есть правильную подсветку должен делать полноценный парсер текста. Причем умный парсер. Никакой капс этого не заменит.
Так это умеет делать любой простенький программерский редактор текстов...
-
Кроме того, такие длинные, громоздкие синтаксические конструкции, как array of integer и тд должны отсутстовать - вот это, в основном, и побудило меня открыть тему.
Вы уж определитесь, для чего Вам нужен язык программирования -- для быстренкого написания простеньких программулек -- запустил и стёр -- или для долговременных проектов, где важна читабельность программ?
-
Также не очень понятно как свести к общему знаменателю Аду и Оберон - скажем в Аде есть generic-модули, в Обероне обобщенки нет вообще. Более того, чтобы скажем в ББ полноценно присутствовал и Оберон и КП, оный ББ придется переписать на их общем знаменателе - Обероне.
Значит Аду вычеркиваем)) Главное - семейство Оберонов. Если серьезно заниматься этим вопросом, то ББ все равно придется переписать хотя бы из-за жлобской лицензии.
-
Вы уж определитесь, для чего Вам нужен язык программирования -- для быстренкого написания простеньких программулек -- запустил и стёр -- или для долговременных проектов, где важна читабельность программ?
и то и другое...
-
А какие конкретно притензии к концструкциям вида "array of SomeType" ? Слишком долго писать? Или слишком долго читать? Или что-то еще?
По моему опыту, это было бы критично есили бы например в Обероне были бы замыкания и/или лямбда функции. Тогда длинный синтаксис объявления переменных больно бил бы по рукам. А поскольку ничего этого в Оберонах (Оберон, Оберон-2, КП) нет, то это не слишком критично.
-
А какие конкретно притензии к концструкциям вида "array of SomeType" ? Слишком долго писать? Или слишком долго читать? Или что-то еще?
Каких-то особых претензий нет. Чисто эстетика. Хотя, может и будет выигрыш при больших объемах кода.
По моему опыту, это было бы критично есили бы например в Обероне были бы замыкания и/или лямбда функции. Тогда длинный синтаксис объявления переменных больно бил бы по рукам. А поскольку ничего этого в Оберонах (Оберон, Оберон-2, КП) нет, то это не слишком критично.
Кстати, стоило бы ввести в Оберон лямбда функции, если убрать обязательный VAR и разрешить объявление переменной в любом месте?
-
Можно посмотреть как лямбды сделаны в Делфи (да, они там теперь есть) и... постараться избежать подобных граблей :-)
Кроме того, советую посмотреть как в Аде не превращаясь в Си сделали объявление переменых не только в "VAR" секции процедуры.
-
1. ИМХО, главное при разработке языка - чего уже нельзя убрать, а не чего еще можно добавить.
Ненужные обобщения приводят к таким монстрам!
2. Если правильный редактор (семантический), то синтаксис языка - пофигу, ибо ручками реально вводятся только имена и выражения. Проверено в первой версии редактора... :)
-
1. ИМХО, главное при разработке языка - чего уже нельзя убрать, а не чего еще можно добавить.
Ненужные обобщения приводят к таким монстрам!
К каким? :-)
По моему, из языка как раз обобщения убирать нельзя, а вот все частные случаи - вполне можно. Ибо их можно сделать библиотечными.
2. Если правильный редактор (семантический), то синтаксис языка - пофигу, ибо ручками реально вводятся только имена и выражения. Проверено в первой версии редактора... :)
На самом деле это не так. Редактор действительно помогает писать. Но синтаксис во время написания как раз по рукам бьет не сильно. Синтаксис влияет на восприятие кода. И длинный, многословный, синтаксис (тех же лямбд например) менее читабелен и воспринимается хуже, чем короткий.
Пример:
sum := map(function (a, b: Integer) : Integer
begin
Exit(a+b);
end,
list);
против
sum = map (\a b -> a+b) list
Нет, желающие, конечно, по старой-доброй обероновской традиции, могут первый вариант вытянуть в одну строку:
sum := map(function (a, b: Integer) : Integer begin Exit(a+b); end, list);
но я не уверен что от этого оно станет лучше читаться :-)
-
1. Следование концепции неймановской архитектуре ДО САМОГО КОНЦА в языке программирования неизбежно приводят к динамическому формированию программы и ее выполнению... :) То есть как ни крути, а все равно Лисп получается... :)
Но в императивных языках этого как раз нет. А должно быть, если следовать принципу обобщения... :)
Но реально-то есть либо указатели на функции, либо некая сущность исполняемого типа. Например, процедурные переменные. Но с ОЧЕНЬ ограниченной функциональностью.
2. В одну строку писать и не надо. Надо писать структурно. Здесь редактор автоматом и обеспечит нужный уровень читабельности.
Если вдумаетесь, то лаконичность написания ( в ущерб читабельности) возникла именно как необходимость набирать ручками каждый символ.
Если редактор берет на себя рутину представления, то и нафига лаконичность?
-
1. Следование концепции неймановской архитектуре ДО САМОГО КОНЦА в языке программирования неизбежно приводят к динамическому формированию программы и ее выполнению... :) То есть как ни крути, а все равно Лисп получается... :)
Но в императивных языках этого как раз нет. А должно быть, если следовать принципу обобщения... :)
Как это нет? А забить массив а потом его исполнить как функцию? Эстеты содержимое массива могут получить прогнав по сгенерированному тексту транслятор, но можно и без изысков.
Ну а про динамическое формирование кода на этапе компиляции я вообще молчу - это ж сплошь и рядом используется.
Но тут, кстати, следует учесть, что львиная доля микропроцессоров таки не следуют (не реализуют) архитектуре фон Неймана, так что фокус не выйдет и для лиспоподобного поведения придется лепить себе эмулятор оной архитектуры, что накладно. не нужно и вообще изврат.
Так что то, что ты привел - это не обобщение на самом деле, самогенерация эта - это забавный, но все же частный случай одной конкретной архитектуры, поэтому зашивать это в язык высокого уровня не стоит.
А вот автоматическое формирование программы на этапе компиляции - это уже общий случай. Это мы можем всегда (когда у нас есть достаточно информации на этапе компиляции) вне зависимости от целевой архитектуры процессора.
2. В одну строку писать и не надо. Надо писать структурно. Здесь редактор автоматом и обеспечит нужный уровень читабельности.
ok. Как он организует мне нужный уровень читабельности вот этого:
sum := map(function (a, b: Integer) : Integer
begin
Exit(a+b);
end,
list);
Этот код не читабелен.
Если вдумаетесь, то лаконичность написания ( в ущерб читабельности) возникла именно как необходимость набирать ручками каждый символ.
В ущерб читабельности - да. Но в данном случае лаконичность описания идет не в ущерб читабельности, а во благо её. А вот многословность, отсутствие лаконичности, тут уже идет как раз в ущерб читабельности.
Если редактор берет на себя рутину представления, то и нафига лаконичность?
Чтобы было читабельно.
-
Кроме того, советую посмотреть как в Аде не превращаясь в Си сделали объявление переменых не только в "VAR" секции процедуры.
Те, которые как бы константы?
-
Кроме того, советую посмотреть как в Аде не превращаясь в Си сделали объявление переменых не только в "VAR" секции процедуры.
Те, которые константы?
Те которые любые в любом, по сути, месте.
-
Собственно вот: http://ada-ru.org/V-0.4w/part_1/ch_03.html#s3.3
Если подумать, то это очень правильное решение. Это в некоторых случаях лучше чем вложенные функции и лучше чем объявление в C99/C++ переменных где попало (собственно в C99/C++ тоже можно примерно так же, но там это не обязательно).
-
В ущерб читабельности - да. Но в данном случае лаконичность описания идет не в ущерб читабельности, а во благо её. А вот многословность, отсутствие лаконичности, тут уже идет как раз в ущерб читабельности.
Есть предложения, какой аналог может быть в Обероне?:
sum = map (\a b -> a+b) list
-
кстати, понравилось в Аде:
if
........
end if;
имхо улучшает читаемость
-
В ущерб читабельности - да. Но в данном случае лаконичность описания идет не в ущерб читабельности, а во благо её. А вот многословность, отсутствие лаконичности, тут уже идет как раз в ущерб читабельности.
Есть предложения, какой аналог может быть в Обероне?:
sum = map (\a b -> a+b) list
В плане синтаксиса, можно посмотреть например сюда: http://wiki.oxygenelanguage.com/en/Lambda_Expressions
Но вообще, с лямдами в Обероне не все так просто. Их ведь там нет, и нет по сути нормальных предпосылок для того, чтобы они появились. То есть их введение затрагивает не только синтаксис, но и грамматику и семантику языка. Для того, чтобы можно было как-то приблизиться к "sum = map (\a b -> a+b) list" нужно ведь в языке иметь хоть какой-то но вывод типов.
-
кстати, понравилось в Аде:
if
........
end if;
имхо улучшает читаемость
В Аде вообще синтаксис весьма и весьма читабелен. То есть читабельней Оберона. При разработке языка там делали упор именно на читабельность. Ядро языка Ада мне очень нравится. А вот дальнейшая эволюция зыка, то что потом вокруг наросло - не очень. Например поддержка ООП там ввели через не правильное место. По крайней мере синтаксически.
Если взять Аду, взять кувалду, и отбить ненужное, нарастить немного недостающего, то можно получить очень приятный язык. Ada lite :-)
-
кстати, понравилось в Аде:
if
........
end if;
имхо улучшает читаемость
Я тоже так когда-то думал :) (в обероне еще в конце процедуры надо ее имя писать). Но на самом деле это борьба со следствием. Первопричина - большие процедуры и многовложенные конструкции (в оберонах, кстати, их очень любят).
-
2. В одну строку писать и не надо. Надо писать структурно. Здесь редактор автоматом и обеспечит нужный уровень читабельности.
Только если он будет "фильтровать" всякий мусор :) Типа ненужных объявлений типа и прочих begin/end в данном примере с лямбдой.
Если вдумаетесь, то лаконичность написания ( в ущерб читабельности) возникла именно как необходимость набирать ручками каждый символ.
Если редактор берет на себя рутину представления, то и нафига лаконичность?
Краткость - сестра :) Не надо путать лакончиность и "птичий язык" :)
-
Если взять Аду, взять кувалду, и отбить ненужное, нарастить немного недостающего, то можно получить очень приятный язык. Ada lite :-)
Не, лучше взять оттуда удачные решения и прикрутить к Oberon-M:)
-
Я тоже так когда-то думал :) (в обероне еще в конце процедуры надо ее имя писать). Но на самом деле это борьба со следствием. Первопричина - большие процедуры и многовложенные конструкции (в оберонах, кстати, их очень любят).
То есть от первопричины не уйти:)
-
Если взять Аду, взять кувалду, и отбить ненужное, нарастить немного недостающего, то можно получить очень приятный язык. Ada lite :-)
Не, лучше взять оттуда удачные решения и прикрутить к Oberon-M:)
И та, и другая затея весьма сомнительны (IMHO). Язык - это не мешок с запчастями, где одни части можно произвольно выкинуть, другие добавить. Оберон, в первую очередь, хорош как раз тем, что он удачно сбалансирован. Малейшие, даже незначительные изменения, по-хорошему надо бы прогонять на множестве задач. Если уж этим заниматься, то начинать нужно с проработки новых концепций. Если же изменения должны коснуться только синтаксиса, то без новых РБНФ разговаривать не о чём.
-
Я тоже так когда-то думал :) (в обероне еще в конце процедуры надо ее имя писать). Но на самом деле это борьба со следствием. Первопричина - большие процедуры и многовложенные конструкции (в оберонах, кстати, их очень любят).
То есть от первопричины не уйти:)
От первопричины оберонщикам мешает уйти догматическое следование принципу единственности RETURN. В свою очередь, желание иметь единственный RETURN возникает прежде всего (если отмести религиозные причины и оставить чисто практические) из-за отсутствия в языке поддержки финализирующих действий (аналога finally/using и т.п. в других языках).
-
Если уж этим заниматься, то начинать нужно с проработки новых концепций. Если же изменения должны коснуться только синтаксиса, то без новых РБНФ разговаривать не о чём.
В основном, речь идет о синтаксисе, но возможно и добавление новых концепций.
В начале, думаю, лучше наметить контуры, в том числе позаимствовав удачные решения с других языков. а затем уже можно и к РБНФ приступить.
-
против
sum = map (\a b -> a+b) list
Я, конечно, понимаю, что речь идет о принципе и извиняюсь за оффтопик.
Но, все-таки, зачем писать такую херню и потом повторять ее десять раз.
Если уж приводить иллюстрацию, то хотя бы корректную.
-
И та, и другая затея весьма сомнительны (IMHO). Язык - это не мешок с запчастями, где одни части можно произвольно выкинуть, другие добавить.
А мы не произвольно, мы по выбору. :-)
Оберон, в первую очередь, хорош как раз тем, что он удачно сбалансирован. Малейшие, даже незначительные изменения, по-хорошему надо бы прогонять на множестве задач.
Я бе не сказал, что Оберон идеально сбалансирован. По крайней мере этот самый баланс не проверялся на множестве задач. Оберон был спроектирован для одной конкретной задачи - написания исследовательской ОС Оберон (которая также весьма специфична).
Если уж этим заниматься, то начинать нужно с проработки новых концепций. Если же изменения должны коснуться только синтаксиса, то без новых РБНФ разговаривать не о чём.
Если уж чем-то начинать заниматься, но вначале нужно определиться - зачем это все :-) Чем мы тут собственно и занимаемся. А РБНФ дело совершенно не хитрое (настолько не хитрое, что РБНФ даже не описывает полностью грамматику Оберона).
Ну, например чтобы поменять синтаксис объявления массивов (как тут было предложено) достаточно изменить правило вывода всего одного нетерминала:
ArrayType = ARRAY length {"," length} OF type.
Поменять на:
ArrayType = type "[" length {"," length} "]".
В результате будет нечто вроде:
a : REAL[10,20,30];
В общем, EBNF - фигня. Было бы понятно зачем и что менять, а EBNF нарисовать не проблема.
-
против
sum = map (\a b -> a+b) list
Я, конечно, понимаю, что речь идет о принципе и извиняюсь за оффтопик.
Но, все-таки, зачем писать такую херню и потом повторять ее десять раз.
Если уж приводить иллюстрацию, то хотя бы корректную.
Как зачем? Для бодрости боевого духа! ;-) Как оказалось, карась не дремлет ;-)
sum = foldr (\a b -> a+b) 0 list
-
В результате будет нечто вроде:
a : REAL[10,20,30];
не понял...
a:[10][20][30] real; //3-х мерный массив?
a:[] int=10,20,30; //объявление массива с инициализацией?
-
В результате будет нечто вроде:
a : REAL[10,20,30];
не понял...
a:[10][20][30] real; //3-х мерный массив?
a:[] int=10,20,30; //объявление массива с инициализацией?
a : REAL[10,20,30]; (* объявление трехмерного массива real'ов *)
А про инициализацию я не думал еще :-)
Вообще, это ж была по сути демонстрация того, что EBNF изменить не сложно, сложно придумать куда менять.
Вообще, чтобы не переливать из пустого в порожнее, предлагаю новые синтаксическо-грамматические предложения оформлять сразу с примером того как плохо было, и как хорошо станет. Однострочные примеры обычно не дают достаточно сильного ощущения, что было плохо, а станет лучше. То есть примеры должны быть более-менее реального размера, чтобы было понятно, что предлагаемое нововведение реально может улучшить жизнь.
-
Переделанный пример из книги Вирта:
module ProgramPattern;
import Texts, Oberon;
w: Texts.Writer; //global writer
proc copy(r: Texts.Reader);
ch: char;
Texts.Read(r, ch);
while ~r.eot do Texts.Write(w, ch); Texts.Read(r, ch) end while
end copy
proc SomeCommand*;
r: Texts.Reader; //local reader
Texts.OpenReader(r, Oberon.This.text, Oberon.Par.pos);
copy(r, w); Texts.Append(Oberon.Log, w.buf)
end SomeCommand;
Texts.OpenWriter(w)
end ProgramPattern.
-
1. ИМХО, главное при разработке языка - чего уже нельзя убрать, а не чего еще можно добавить.
Брейнфак никому, кроме эзотериков, не нужен.
А ведь из брейнфака действительно уже нечего убрать, то есть идеал с Вашей точки зрения...
-
Насчет читабельности.
Видимо, читабельность - разная для разного уровня подготовки. То, что новичку читабельно, профи - лишний мусор.
И наоборот. То, что для профи читабельно, для новичка - китайская грамота.
Таким образом, просто нужны РАЗНЫЕ языки.
Насчет минимизации.
ИМХО Си - наилучший пример минимизации.
А С++ - наихудший... :)
-
Насчет читабельности.
Видимо, читабельность - разная для разного уровня подготовки. То, что новичку читабельно, профи - лишний мусор.
И наоборот. То, что для профи читабельно, для новичка - китайская грамота.
......
ЯП
Ну да, все опять свелось определению области оптимального использования ЯП , точнее к расширению ее...
to Веселовский: это вопрос периодически муссируется здесь и в к коровнике, и вроде очевидна бесперспективность его обсуждения с "наивной" программерской позиции - есть другие языки, попробовал их конструкции на СВОИХ задачах, понравилось, написал... Может более перспективным (с точки зрения полезности обсуждния) будет проектировать язык исходя из области его использования? Скажем с Оберонами возможен такой план
1. Определяемся с областью его оптимального использования
2. Как можно четче описываем ту область на которую мы хотим его расширить
3 Отображаем исходный Оберон на то что ХОТИМ получить
-
Может более перспективным (с точки зрения полезности обсуждния) будет проектировать язык исходя из области его использования? Скажем с Оберонами возможен такой план:
1. Определяемся с областью его оптимального использования
2. Как можно четче описываем ту область на которую мы хотим его расширить
3 Отображаем исходный Оберон на то что ХОТИМ получить
Хорошая идея. В соответствии с этим подходом, предлагаю обсудить вебпрограммирование(серверные приложения - к примеру, движек динамического сайта - социалка, портал, форум, магазин и т.д.), как область оптимального использования. В КП уже сделан в этом направлении шаг - добавили работу со строками.
-
В направлении серверного программирования есть еще один плюс: если дело дойдет до создания компилятора, то гораздо легче будет сделать Линуксовую версию, так как Гуй не нужен.
-
В направлении серверного программирования есть еще один плюс: если дело дойдет до создания компилятора, то гораздо легче будет сделать Линуксовую версию, так как Гуй не нужен.
Вообще то компилятор никакого отношения к гую не имеет. Одно с другим не связано никак.
-
Вообще то компилятор никакого отношения к гую не имеет. Одно с другим не связано никак.
Не нужны гуевые библиотеки, ide
-
Вообще то компилятор никакого отношения к гую не имеет. Одно с другим не связано никак.
Не нужны гуевые библиотеки, ide
IDE нужно/не нужно вне зависимости от того пишешь ты линуксовый серверный софт, или же гуёвое виндовозное приложение.
GUI-либы вообще мало отличаются от сетевых либ. Особенно под линуксом. Приложение которое под хрюниксом хочет иметь окошко (и что-то в нем рисовать) вполне по TCP либо по Unix Domain Socket'у шлет X11-серверу запрос и далее общается с ним по сети.
Чем это отличается, скажем, от http-сервера или клиента? :-)
-
Хорошая идея. В соответствии с этим подходом, предлагаю обсудить вебпрограммирование(серверные приложения - к примеру, движек динамического сайта - социалка, портал, форум, магазин и т.д.), как область оптимального использования. В КП уже сделан в этом направлении шаг - добавили работу со строками.
Че ж сразу серверное? Я вот клиентское хочу. Жабаскрипт задолбал.
-
Че ж сразу серверное? Я вот клиентское хочу. Жабаскрипт задолбал.
Ну, давайте все веб направление возьмем: клиентское+серверное
-
1. Определяемся с областью его оптимального использования
2. Как можно четче описываем ту область на которую мы хотим его расширить
3. Отображаем исходный Оберон на то что ХОТИМ получить
Ещё неплохо бы определиться с целевой аудиторией, а то необязательные потребности у них могут перевесить все достоинства нового языка...
-
Ещё неплохо бы определиться с целевой аудиторией, а то необязательные потребности у них могут перевесить все достоинства нового языка...
Гхм. Программисты? :) Во всяком случае я бы не стал делать упор исключительно на обучающихся студентов. Это не значит, что нужно сделать эзотерическеую вещь. Просто если будет выбор "удобно/идеологически правильно" против "не сразу понятно и не так как везде", то обучающиеся в проигрыше.
-
Добавлю пример с соседнего форума, автор Jordan:
Исходный код:
PROCEDURE Max(VAR: a, b: INTEGER): INTEGER;
VAR
Result: INTEGER;
BEGIN
IF a > b THEN
Result := a;
ELSE
Result := b;
END;
RETURN Result;
END Max;
Убираем RETURN, PROCEDURE, BEGIN, THEN
Max(a, b: INTEGER): INTEGER;
IF (a > b)
Max := a;
ELSE
Max := b;
END;
Max;
Убрать PROCEDURE - идея интересная.
Мой вариант:
Max(a, b: int): int;
Result: int;
if a > b then Result := a else Result := b
end if;
return Result;
end Max;
-
На счет убираний PROCEDURE - не знаю не знаю. Тут надо думать. Дело в том, что это самое убирание может превратить язык из LL(1) в нечто более сложное.
PS. Нет, само представление грамматики РБНФ сложнее не станет (вообще говоря), сложнее станет грамматика сама по себе и парсер. Что не страшно в двух случаях: 1) если есть некто достаточно компетентный кто сможет реализовать такой парсер (это не слишком сложно, но тут уже надо быть в теме, по книжке Вирта это с наскоку уже не сделать). 2) Если это никто не собирается делать вообще.
-
На всякийслучай поясню: я не считаю что "о боже, они хотят усложнить грамматику языка!!! Та делать нельзя!!1 на костер их ". Я просто указываю на потенциальные грабли которые могут когда-нибудь стукнуть по лбу. Так сказать, крашу эти грабли в яркий цвет, что бы видны были.
Их можно обойти, или даже не почувствовать. Например если для написания парсера использовать coco/r, то удар будет чувствительный. Если использовать parsec, то можно вообще ничего не ощутить.
-
Если я правильно понял, LL- парсеры воспринимают код жестко слева направо. В модифицированном синтаксисе, который мы рассматриваем, это не прокатит, так как требуется некое распознавание кода.
-
Если уж дальше идти в сторону радикального улучшения синтаксиса, то следует вспомнить о значимых отступах и питоноподобном синтаксисе.
Напоминаю о сообщении Криса Окасаки о том, что студентам сильно мешают синтаксические скобки (неважно, { .. } это, begin .. end или if .. end if):
In praise of mandatory indentation for novice programmers (http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html)
-
Добавлю пример с соседнего форума, автор Jordan:.....
Ж) Вот хороший пример того , к чему приводит бездумное фичевание... помимо бегинов под нож попали и var ы- и как по - вашему бедному проггеру помечать выходные переменные? или они не планируются ж)?
-
Если уж дальше идти в сторону радикального улучшения синтаксиса, то следует вспомнить о значимых отступах и питоноподобном синтаксисе.
Напоминаю о сообщении Криса Окасаки о том, что студентам сильно мешают синтаксические скобки (неважно, { .. } это, begin .. end или if .. end if):
In praise of mandatory indentation for novice programmers (http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html)
Поэтому я в Си пишу без них вообще.
-
Поэтому я в Си пишу без них вообще.
Без {}?, :) а я вот не могу - научите?
-
Использую оператор ",":
Пример:
#include <stdlib.h>
#include <stdio.h>
#define MAX(a,b) ((a)>(b) ? (a) : (b))
int main()
{
int a, b, c;
if (3!=scanf("%d %d %d", &a, &b, &c))
fprintf(stderr, "Triangle side length must be natural number.\n"),
exit(1);
int max = MAX(a, MAX(b,c));
printf("%s\n", a*a + b*b + c*c == max*max*2 ? "Yes" : "No");
return 0;
}
-
Вот хороший пример того , к чему приводит бездумное фичевание... помимо бегинов под нож попали и var ы- и как по - вашему бедному проггеру помечать выходные переменные? или они не планируются ж)?
Max(a, b: int): int;
Result: int;
if a > b then Result := a else Result := b end if;
return Result;
end Max;
Можно подробней, что не так с выходными переменными?
-
Использую оператор ",":
Для примера приведенного вами пойдет, для того, что мне нужно было на ПРАКТИКЕ - ужасно.
-
Если уж дальше идти в сторону радикального улучшения синтаксиса, то следует вспомнить о значимых отступах и питоноподобном синтаксисе.
Напоминаю о сообщении Криса Окасаки о том, что студентам сильно мешают синтаксические скобки (неважно, { .. } это, begin .. end или if .. end if):
In praise of mandatory indentation for novice programmers (http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html)
Поэтому я в Си пишу без них вообще.
Не поэтому, а вопреки!
if (3!=scanf("%d %d %d", &a, &b, &c))
fprintf(stderr, "Triangle side length must be natural number.\n");
exit(1);
Вот тут прогер поставил не запятую, а точку с запятой -- это баг? Или так и должно быть?
Скобки или значимые отступы всё расставили бы по местам, а так только плодится глюкософт!!!111
-
printf("%s\n", a*a + b*b + c*c == max*max*2 ? "Yes" : "No");
а это вообще лучше уж так переписать:
printf(a*a + b*b + c*c == max*max*2 ? "Yes\n" : "No\n");
-
Скобки или значимые отступы всё расставили бы по местам, а так только плодится глюкософт!!!111
:) Даже тут не все однозначно - с год назад дал студентам задачу, написать программу пирамидальной сортировки по Кормену -от студентов ЧЕТКО требовалось 1. Разобраться с синтаксисом алгоритмического языка (на котором Кормен и К описывают алгоритмы). 2 сделать проекцию на базовые императивные понятия, 3 Написать написать программу на Паскале. Так вот, лучшие не написали по одной причине - у Кормена блоки виделялись отступами(как в Питоне) , а при печати строчки поползли + шрифт использовался с литерами различной ширины :)
-
Напоминаю о сообщении Криса Окасаки о том, что студентам сильно мешают синтаксические скобки (неважно, { .. } это, begin .. end или if .. end if):
In praise of mandatory indentation for novice programmers (http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html)
Довольно странно читать подобные рассуждения, когда много месяцев работаешь с такой картинкой (сам код не мой).
(http://s006.radikal.ru/i213/1201/16/cbbbcd3879af.png)
Как говорил Риббентроп, я спросил себя: "А не дурак ли он?" (c)
-
Можно подробней, что не так с выходными переменными?
В исходном примере - переменные передаваемые в подпрограммы были помечены служебным словом var, в "улучшенных" - нет - это не одно и тоже. Разумеется, можно без пометки в ряде случаев обойтись - например, используя глобальные переменные, но это "рецепт" в чем- то аналогичен предложению Алексея , по замене операторных скобок.
-
Напоминаю о сообщении Криса Окасаки о том, что студентам сильно мешают синтаксические скобки (неважно, { .. } это, begin .. end или if .. end if):
In praise of mandatory indentation for novice programmers (http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html)
Довольно странно читать подобные рассуждения, когда много месяцев работаешь с такой картинкой (сам код не мой).
(http://s006.radikal.ru/i213/1201/16/cbbbcd3879af.png)
Как говорил Риббентроп, я спросил себя: "А не дурак ли он?" (c)
Ну вот, у кого-то есть такие костыли, а в моих средствах разработки такого нет...
-
Ну вот, у кого-то есть такие костыли, а в моих средствах разработки такого нет...
- Вот если бы я с вами пошел...
- Ну так в чем дело? Пошли!
(с)
-
Гм. Что-то я не понял. Отступы что со скобочками что без скобочек никуда не деваются. То есть они есть. Скобочки еще явнее выделяют блок/конструкцию (имеем отступ+скобочки). + еще и IDE нам может нарисовать докучи всяких пометок (что смотрится уже излишним).
Думаю скобочки плохи в одном случае - когда мы имеем в коде нечто вроде такого:
}
}
}
}
}
}
Но такая глубокая вложенность вообще признак того, что следует что-то в консерватории править. Тем более, что отсутствие скобочек (использование только отступов) сделает код еще менее понятным (и потенциально больше ошибок будет, да) в таком случае:
}
}
foo();
}
bar();
}
}
zoo();
}
Тут если скобочек нет, то остается уповать лишь на IDE'шные костыли.
-
\
- Вот если бы я с вами пошел...
- Ну так в чем дело? Пошли!
(с)
:) Точно, не фиг юродствовать , и обобщать ущербность на всех!!
Но вот ведь какая штука - не всегда и это возможно , помнится работая в одной конторе, нас работодатели -американы держали долго на VS5 без приблуд, хотя уже вроде как 4 года существовала 6 - ка с прибомбасами....
-
В исходном примере - переменные передаваемые в подпрограммы были помечены служебным словом var, в "улучшенных" - нет - это не одно и тоже. Разумеется, можно без пометки в ряде случаев обойтись - например, используя глобальные переменные, но это "рецепт" в чем- то аналогичен предложению Алексея , по замене операторных скобок.
Max(a, b: int): int;
a, b: int - это в точности: VAR a, b: INTEGER
-
(http://s006.radikal.ru/i213/1201/16/cbbbcd3879af.png)
На этом примере прекрасно видно недостатки квадратных скобок по сравнению с конструкцией:
if........then
............
else......
end if;
-
Max(a, b: int): int;
a, b: int - это в точности: VAR a, b: INTEGER
Хе, даже так, плохо , а как вы вызовите Max(a+5,10) ? ):
-
На этом примере прекрасно видно недостатки квадратных скобок по сравнению с конструкцией ...
Честно признаюсь, что не вижу ни квадратных скобок, ни того, о каких недостатках идет речь. Напишите поподробней.
-
Честно признаюсь, что не вижу ни квадратных скобок, ни того, о каких недостатках идет речь. Напишите поподробней.
Прошу прощения, фигурных, конечно же. Недостатки - излишество скобок по сравнению с обероновской конструкцией if.....end
-
Max(a, b: int): int;
a, b: int - это в точности: VAR a, b: INTEGER
Как оберонщик могу сказать, что это не одно и то же. В первом случае константы МОГУТ быть переданы в процедуру в качестве фактических параметров, во втором случае - не могут.
-
Max(a, b: int): int;
a, b: int - это в точности: VAR a, b: INTEGER
Как оберонщик могу сказать, что это не одно и то же. В первом случае константы МОГУТ быть переданы в процедуру в качестве фактических параметров, во втором случае - не могут.
Правильнее сказать ЗНАЧЕНИЯ (не только литерных или именованных констант, но и переменных и вы выражений содержащих все предыдущее плюс результаты вызовов функций...), по этому во всех грамотных (и не очень) книгах по программированию начального уровня, такой способ передачи фактических параметров так и называется - передачей по значению....-оберон это или си - без разницы, если речь идет об императивном ЯВУ
-
Брейнфак никому, кроме эзотериков, не нужен.
А ведь из брейнфака действительно уже нечего убрать, то есть идеал с Вашей точки зрения...
А вот если в брейнфак добавить лямбды...
-
Брейнфак никому, кроме эзотериков, не нужен.
А ведь из брейнфака действительно уже нечего убрать, то есть идеал с Вашей точки зрения...
А вот если в брейнфак добавить лямбды...
Лямбды это не синтаксис :-) (хотя без дОлжного синтаксиса они бессмысленны).
Кстати, действительно интересно - брейнфайк ведь по сути язык машины Тьюринга. Лямбды там действительно некуда засунуть. Императивные языки растут из машины тьюринга же, но чем выше уровень императивного языка, тем более уместными кажутся там лямбды.
Причем в функциональных языках аналогично - чем выше уровень функционального языка, тем более уместны там простые последовательности действий, процедуры.
То есть высокоуровневый язык позволяет абстрагироваться от самой сути исполнителя - становится все равно, тьюринг машина у нас там внизу, или же лямбда-термы разворачиваются. Позволяет использовать те абстракции, инструменты, которые нам удобны здесь и сейчас.
-
То есть высокоуровневый язык позволяет абстрагироваться от самой сути исполнителя - становится все равно, тьюринг машина у нас там внизу, или же лямбда-термы разворачиваются. Позволяет использовать те абстракции, инструменты, которые нам удобны здесь и сейчас.
А почему они "удобны здесь и сейчас"?
-
Что думаете насчет использования в синтаксисе правильных логических обозначений?:
≠, ≤, ≥, , ∧, ∨
-
Что думаете насчет использования в синтаксисе правильных логических обозначений?:
≠, ≤, ≥, , ∧, ∨
Думаю что это хорошо и своевременно. Но обзательно должно дублироваться альтернативными символами когда эти символы не доступны. Ну это например как в C++ оператор && дублируется ключевым словом "and".
-
≠ #
≤ <=
≥ >=
not
∧ and
∨ or
⊻ xor
⊼ nand
⊽ nor
возможно, придется заменить значек ^ работы с указателями, чтобы не перепутать с and
-
≠ #
≤ <=
≥ >=
not
∧ and
∨ or
⊻ xor
⊼ nand
⊽ nor
возможно, придется заменить значек ^ работы с указателями, чтобы не перепутать с and
И привязывать язык к IDE? - а попробуйте сделать это на ББ, вроде последняя версия работает с юникодом.. принцип трансляции в стандартный КП аналогичен тому ,как ИНФО21 транслирует русские слова, вроде достаточно расширить его подсистему...
-
≠ #
≤ <=
≥ >=
not
∧ and
∨ or
⊻ xor
⊼ nand
⊽ nor
возможно, придется заменить значек ^ работы с указателями, чтобы не перепутать с and
Вот скажите, оно стоит усилий, которые предлагается потратить? Вот кому оно реально надо? Не просто "хотелось бы", "было бы прикольно" и т.п., а реальная необходимость или хотя бы удобство? Бывают, конечно, случаи, когда самому делать неохота, но готовым результатом воспользовался бы. Но вот этим даже пользоваться не хочется.
-
Вот скажите, оно стоит усилий, которые предлагается потратить? Вот кому оно реально надо? Не просто "хотелось бы", "было бы прикольно" и т.п., а реальная необходимость или хотя бы удобство? Бывают, конечно, случаи, когда самому делать неохота, но готовым результатом воспользовался бы. Но вот этим даже пользоваться не хочется.
Возможно это будет интересно если профилировать ББ в систему для начального обучения, (введение такого рода обозначений облегчает восприятие алгоритма, программы ) - но вот ведь какая штука:
1. Восприятие ДОЛЖНО быть улучшено (замена символов - всего лишь составная часть из НЕОБХОДИМОГО комплекса мер)
2. Второй момент, должно быть обеспечено УДОБСТВО использования этой фичи.
Если эти условия не будут выполнены, то такую работу ждет участь БОЛЬШИНСТВА компонент - поделок из коллекции Цина.Хороший пример - известные реализации подсистемы подсветки синтаксиса в ББ - в том виде как они РЕАЛИЗОВАНЫ - они НАХРЕН никому не нужны -"гениальность" коровцев заключается в заключении о том, что они не нужны ВООБЩЕ :D , и даже подгонки под этот тезис определенной "теории".
from valexey: исправил кодировку.
-
... в C++ оператор && дублируется ключевым словом "and".
о_О серьёзно???
-
Зачем вообще логические и побитовые операции обозначать по-разному, если и так однозначно определяется какой тип операции.
Кто что может сказать про гуглевский язык Go? Есть мнения, что это изощренно испоганенный оберон.
-
Кто что может сказать про гуглевский язык Go? Есть мнения, что это изощренно испоганенный оберон.
Скорее испоганенный Limbo.
PS. Не стоит видеть во всем что имеет модуль и сборщик мусора, Оберон :-)
-
... в C++ оператор && дублируется ключевым словом "and".
о_О серьёзно???
Да, конечно. Но тут не стоит путать C++ с Си.
-
Зачем вообще логические и побитовые операции обозначать по-разному, если и так однозначно определяется какой тип операции.
Для логических операций возможно ленивое вычисление. Оберонщики расскажут насколько это важно в трехэтажных предикатах правильных циклов :) Впрочем и необеронщики находят такой свойство весьма полезным. Битовые операции - вычисляются полностью.
-
В теме было предложено, чтобы модифицированный оберон кроме присущей ему универсальности был также удобен для разработки веб приложений и для программирования микроконтроллеров. Предлагаю обсудить, какую функциональность еще можно добавить языку для этих целей, помимо той, что появилась в КП и Оберон-07(М).
-
В теме было предложено, чтобы модифицированный оберон кроме присущей ему универсальности был также удобен для разработки веб приложений и для программирования микроконтроллеров. Предлагаю обсудить, какую функциональность еще можно добавить языку для этих целей, помимо той, что появилась в КП и Оберон-07(М).
В плане синтаксиса ничего специфичного для микроконтроллеров не нужно. В плане семантики - может быть и нужно.
-
Еще мысли по поводу упрощения синтаксиса. Отказываемся от ключевых слов TYPE, PROCEDURE, CONST.
Константы:
N = 100
limit = 2*N -1
Объявление типов:
Table = [N] real
Tree = ^Node
Node = rec key: int; left, right: Tree end rec
CenterNode = rec (Node)
name: [32] char;
subnode: Tree
end rec
Function1 = (x: int): int
-
Объявление процедуры:
ReadInt(x: int);
i : int := 0; ch: char;
Read(ch);
while ("0" <= ch) & (ch <= "9") do
i := 10*i + (ORD(ch)-ORD("0")); Read(ch)
end while;
x := i
end ReadInt
-
Какие на ваш взгляд ресурсы необходимы для написания полноценного 64 битового оптимизирующего компилятора обероноподобного ЯП? Возможно ли это сделать небольшой коммандой энтузиастов?
-
Компилятор малополезен без хорошей библиотеки и удобной среды разработки.
Как-то на оберонкоре оценивали стоимость подобной разработки, вышло не менее миллиона долларов )))
-
Какие на ваш взгляд ресурсы необходимы для написания полноценного 64 битового оптимизирующего компилятора обероноподобного ЯП? Возможно ли это сделать небольшой коммандой энтузиастов?
Смотря насколько оптимизирующего :-)
В первом приближении - месяц-два рабочего времени. Месяц на компилятор, месяц на рантайм и отладку. Это если конечно не пытаться написать компилятор на нем самом, а использовать реально предназначенный для этого уже готовый современный инструментарий.
Да, это без учета проектирования языка. То есть скажем взяли Oberon-07, и реализуем.
-
Да, моя оценка - это без богатых либ, отладчика и IDE. Чисто компилятор + рантайм.
-
Да, моя оценка - это без богатых либ, отладчика и IDE. Чисто компилятор + рантайм.
Вопрос ЗАЧЕМ ?- ведь у нас есть опыт Rifat'a...
-
Да, моя оценка - это без богатых либ, отладчика и IDE. Чисто компилятор + рантайм.
Вопрос ЗАЧЕМ ?- ведь у нас есть опыт Rifat'a...
Понятия не имею :-) Тут спросили оценку, я оценку дал. Зачем - виднее автору вопроса.
-
Да, моя оценка - это без богатых либ, отладчика и IDE. Чисто компилятор + рантайм.
Вопрос ЗАЧЕМ ?- ведь у нас есть опыт Rifat'a...
У Рифата 32-битный компилятор, а тут речь про 64-битный...
-
В первом приближении - месяц-два рабочего времени. Месяц на компилятор, месяц на рантайм и отладку. Это если конечно не пытаться написать компилятор на нем самом, а использовать реально предназначенный для этого уже готовый современный инструментарий.
То есть скажем взяли Oberon-07, и реализуем.
Без сборщика мусора?
Да, моя оценка - это без богатых либ, отладчика и IDE. Чисто компилятор + рантайм.
Насчет IDE, на соседнем форуме обсуждают возможность создания на основе SDL, так что можно потом к ним присоединиться. Отладчика и богатых либ нет и сейчас, даже для ББ.
Вопрос ЗАЧЕМ ?- ведь у нас есть опыт Rifat'a
Опыт учтем: хорошая лицензия и наличие комманды.
-
У Рифата 32-битный компилятор, а тут речь про 64-битный...
Очень смешно .
-
В первом приближении - месяц-два рабочего времени. Месяц на компилятор, месяц на рантайм и отладку. Это если конечно не пытаться написать компилятор на нем самом, а использовать реально предназначенный для этого уже готовый современный инструментарий.
То есть скажем взяли Oberon-07, и реализуем.
Без сборщика мусора?
Со сборщиком (собственно это и есть львиная доля рантайма).
Да, моя оценка - это без богатых либ, отладчика и IDE. Чисто компилятор + рантайм.
Насчет IDE, на соседнем форуме обсуждают возможность создания на основе SDL, так что можно потом к ним присоединиться. Отладчика и богатых либ нет и сейчас, даже для ББ.
На базе SDL IDE будет весьма убогой. Если интересно пообсуждать, заведи тему рядом. Уж SDL то точно к синтаксису языка отношения не имеет :-)
-
Со сборщиком (собственно это и есть львиная доля рантайма).
Интересным был бы вариант с выбором ручной или автоматической сборкой мусора.
-
Со сборщиком (собственно это и есть львиная доля рантайма).
Интересным был бы вариант с выбором ручной или автоматической сборкой мусора.
Понятно что это можно сделать. Вопрос в том, как это должно быть оформленно.
-
Имхо на IDE не нужно вначале концентрировать внимание. Главное - это рабочие компилятор и рантайм под винду и линукс, а затем уже либы и IDE с отладчиком.
-
Имхо на IDE не нужно вначале концентрировать внимание. Главное - это рабочие компилятор и рантайм под винду и линукс, а затем уже либы и IDE с отладчиком.
Это уже от языка и от целевой аудитории и ниши зависит. Есть языки которые прекрасно себя чувствуют без IDE и сделать IDE для них весьма затруднительно (C++ например). А есть языки которые совсем без IDE плохи, малоюзабельны и вообще... но вот IDE под них делается с полпинка и уже связка этого языка с IDE дает отличный инструмент которым удобно и приятно решать задачи (это например java).
Ну, а кроме того есть класс людей которые без IDE на язык не посмотрят вообще (и их довольно много).
-
Смотря насколько оптимизирующего :-)
В первом приближении - месяц-два рабочего времени. Месяц на компилятор, месяц на рантайм и отладку. Это если конечно не пытаться написать компилятор на нем самом, а использовать реально предназначенный для этого уже готовый современный инструментарий.
Да, это без учета проектирования языка. То есть скажем взяли Oberon-07, и реализуем.
Да, я бы тоже так оценил. Непосредственно на компилятор может и недели две. Но, чтоб этим можно было хоть как-то пользоваться за пределами hello world - месяца два.
-
А есть ли возможность 64 битовый компилятор оберона написать не на самом себе? Ведь нет исходной 64 битовой реализации. Придется, наверное С использовать.
-
А есть ли возможность 64 битовый компилятор оберона написать не на самом себе? Ведь нет исходной 64 битовой реализации. Придется, наверное С использовать.
Не понял. Писать компилятор в с оберона в AMD64 можно на чем угодно, хоть на прологе, хоть на рефале, хоть на брейнфаке или c++.
-
А есть ли возможность 64 битовый компилятор оберона написать не на самом себе? Ведь нет исходной 64 битовой реализации. Придется, наверное С использовать.
Конечно надо писать используя нормальный инструмент, а не доказывать самодостаточность оберонов :)
P.S. Я бы начал с LLVM.
-
Не совсем в тему. Почитал тут про Модулу3. Разделение Record и Object хорошая идея.
-
Суровые мужики тут собрались. Один суровый мужик за месяц компилятор Оберона в AMD64 может написать, другой ещё более суровый мужик справится за две недели...
Может оно и так, но только перед этим IMHO надо несколько лет учиться компиляторописательству. Первый в своей жизни компилятор может быть напишешь года за два, второй компилятор за год, третий за полгода, а там глядишь и в самом деле компилятор Оберона за две недели осилишь :) :) :)
-
Не совсем в тему. Почитал тут про Модулу3. Разделение Record и Object хорошая идея.
Дак это ж разделение оно и в C# в D и в Active Oberon.
Но идея да. Разумная во многих случаях.
-
Суровые мужики тут собрались. Один суровый мужик за месяц компилятор Оберона в AMD64 может написать, другой ещё более суровый мужик справится за две недели...
Может оно и так, но только перед этим IMHO надо несколько лет учиться компиляторописательству. Первый в своей жизни компилятор может быть напишешь года за два, второй компилятор за год, третий за полгода, а там глядишь и в самом деле компилятор Оберона за две недели осилишь :) :) :)
А мы вообще круты в самомнении своем. :-)
-
Суровые мужики тут собрались. Один суровый мужик за месяц компилятор Оберона в AMD64 может написать, другой ещё более суровый мужик справится за две недели...
Может оно и так, но только перед этим IMHO надо несколько лет учиться компиляторописательству. Первый в своей жизни компилятор может быть напишешь года за два, второй компилятор за год, третий за полгода, а там глядишь и в самом деле компилятор Оберона за две недели осилишь :) :) :)
А мы вообще круты в самомнении своем. :-)
И при этом гуманны до невозможности - никаких эцилопов!
-
Не совсем в тему. Почитал тут про Модулу3. Разделение Record и Object хорошая идея.
Дак это ж разделение оно и в C# в D и в Active Oberon.
Но идея да. Разумная во многих случаях.
В чём же полезность такой идеи? Почему это разумно?
Имеются в виду сишарпные ссылочные типы (классы) и значимые типы (скаляры и структуры)?
-
Суровые мужики тут собрались. Один суровый мужик за месяц компилятор Оберона в AMD64 может написать, другой ещё более суровый мужик справится за две недели...
Может оно и так, но только перед этим IMHO надо несколько лет учиться компиляторописательству. Первый в своей жизни компилятор может быть напишешь года за два, второй компилятор за год, третий за полгода, а там глядишь и в самом деле компилятор Оберона за две недели осилишь :) :) :)
Ну я говоря о неделях имел ввиду конкретно LLVM. Это готовый бакенд. Т.е. надо написать парсер (я бы даже чужой не стал брать - возни больше) и изучить доку по использованию LLVM. Да, всем программерам свойственно ошибаться в своих временных оценках - ну умножь на число пи, получишь реально реальные сроки :)
-
Ну я говоря о неделях имел ввиду конкретно LLVM. Это готовый бакенд. Т.е. надо написать парсер (я бы даже чужой не стал брать - возни больше) и изучить доку по использованию LLVM. Да, всем программерам свойственно ошибаться в своих временных оценках - ну умножь на число пи, получишь реально реальные сроки :)
Аналогично. А также например я не рассматривал разработку компоновщика с ковырянием во всяких там elf/pe и прочем. Сказано же - компилятор + рантайм c использованием современного инструментария специально для этого предназначенного.
-
Ну я говоря о неделях имел ввиду конкретно LLVM. Это готовый бакенд. Т.е. надо написать парсер (я бы даже чужой не стал брать - возни больше) и изучить доку по использованию LLVM.
Боюсь, там месяца два уйдет на изучение доки. ;)
-
Ну я говоря о неделях имел ввиду конкретно LLVM. Это готовый бакенд. Т.е. надо написать парсер (я бы даже чужой не стал брать - возни больше) и изучить доку по использованию LLVM.
Боюсь, там месяца два уйдет на изучение доки. ;)
Ты драматизируешь. Мне какое-то время назад это было интересно, так что я вечерком под настроение ковырял эту штуку. Довел до состояния "сгенерировать функцию, которая принимает аргумент, делает арифметическую операцию с ним и вызывает "внешнюю" функцию с полученным результатом". Потратил в сумме часов 15. Потом мне стало не очень интересно, потому что дальше уже все понятно :) Хотя вот посмотреть на предмет прикручивания туда GC - тоже было бы интересно (готового нет, но возможность предусмотрена, согласно доке).
-
LLVM имеет частичную поддержку следующих платформ: Windows x86
AMD64 под винду похоже не поддерживает
-
LLVM имеет частичную поддержку следующих платформ: Windows x86
AMD64 под винду похоже не поддерживает
Там какие-то тулзы недоступны. Оно вообще винду "partial support". Тем не менее это не мешало моим экспериментам на винде.
-
LLVM имеет частичную поддержку следующих платформ: Windows x86
AMD64 под винду похоже не поддерживает
Там какие-то тулзы недоступны. Оно вообще винду "partial support". Тем не менее это не мешало моим экспериментам на винде.
Может не поддерживает винду, просто из-за того, что нет фронтенда?
-
Есть такой проект: Оберс - транслятор Оберона2 в NASM. Насколько сложно сделать, скажем транслятор в FASM?
-
Еще один недостаток LLVM - легкость дизасемблирования.
-
Еще один недостаток LLVM - легкость дизасемблирования.
Откуда там вдруг легкость дизассемблирования? На выходе обычный машкод целевой архитектуры.
-
Еще один недостаток LLVM - легкость дизасемблирования.
Не буду сомневаться в достоверности этого высказывания... Спрошу лучше - а почему недостаток-то? И куда дизассемблировать? В LLVM IL?
-
Может не поддерживает винду, просто из-за того, что нет фронтенда?
Какого фронтенда? Еще раз: я получал байткод и исполнял его. На винде. Это видится вполне достаточным для "попробовать написать компилятор оберона (включая АМД64) на коленке". Никто не предлагает намертво завязываться на LLVM. Предлагается его взять как готовый работающий бакенд и сосредоточится на фронтенде (компилятор без кодогенерации + рантайм).
-
Предлагаю кратко рассмотреть удачные идеи в других языках, которые можно было бы перенести в модифицированный Оберон. Не только то, что относится к синтаксису. К примеру, из таких языков: Ада, Модула3, Zonnon, Objective-C, D, C#, Python
-
Ну если верить AlexUs'у что "буквы" определяют все - то в первую очередь нужно менять название :) ;) - ибо существующее дискредитировало себя :D
-
Ну если верить AlexUs'у что "буквы" определяют все - то в первую очередь нужно менять название :) ;) - ибо существующее дискредитировало себя :D
А еще оберон ужасно гуглится. Особенно в рунете - поисковики постоянно выдают ссылки на шарлатанский чудоаппарат для медицинской диагностики Оберон.
-
А еще оберон ужасно гуглится. Особенно в рунете - поисковики постоянно выдают ссылки на шарлатанский чудоаппарат для медицинской диагностики Оберон.
:) Это символично -у нас продукт высоких когнитивных технологий - универсальная пилюля в сфере информатики и программирования, у них в области медицины и диагностики.... Блин ОЧКО в пользу гипотезы AlexUs'a - однако, замечу что косвенное
-
Есть предположение, что все это из за близости к слову лохотрон (оберон - лохотрон) -вызывающему в современной Российской действительности негативные ассоциации :D
-
А еще оберон ужасно гуглится. Особенно в рунете - поисковики постоянно выдают ссылки на шарлатанский чудоаппарат для медицинской диагностики Оберон.
Да ладно, уж не хуже чем Go или Clean ;)
-
Предлагаю кратко рассмотреть удачные идеи в других языках, которые можно было бы перенести в модифицированный Оберон. Не только то, что относится к синтаксису. К примеру, из таких языков: Ада, Модула3, Zonnon, Objective-C, D, C#, Python
Тут такая штука... (всё сказанное далее IMHO)...
Оберон или Паскаль или Модула... никакой принципиальной разницы нет... даже Си, по большому счёту не так плох, как его малюют... Не надо делать "супер-язык"... Н. Вирт прав, когда стремится к минималистичности... (не в ущерб полноте и выразительности, как в Обероне...). Есть задачи программирования и они должны иметь инструменты для их решения. Перечисленные языки вполне успешно решают эти задачи. Но подходит момент, когда задачи уже не поддаются спецификации, они разрастаются и множатся (делением). Тех. задание перестаёт быть заданием тех... оно становится заданием кого угодно и когда угодно, требования к программе меняются по мере её создания, и, в конечном итоге, вместо мусорного ведра получаем ракету... иногда... наоборот... Но эту проблему не решить с помощью "супер-языка"... Нужно явно выделять стадии моделирования и проектирования, чего в "коровнике" ((с) DIzer) не понимают и не принимают... Однако и это ещё не всё... Если всё же стадии моделирования и проектирования обособляются, то становится понятно, что создавать надо не программу, а систему... но система не решает частных задач, она является основой... платформой для решения многих и разных (по классу) задач. А значит нужен принципиально другой подход... нужно моделировать и проектировать не задачу, а инструменты для решения задач. А это совсем иное... и средства совсем другие... то есть, языки программирования здесь... фиолетовы... нужны языки описания предметной области, как... среды конструирования, например. Да, да, да, конечно... ООП, компонентный подход... здорово!.. Но мы же понимаем, что классы и компоненты собираются внутри проекта... а создаются и развиваются вне его. Они элементы архитектуры, которые не слишком зависят от тех кирпичей, из которых будет возводиться здание...
В общем... простой совет: не ищите счастья... наслаждайтесь им.
-
Предлагаю кратко рассмотреть удачные идеи в других языках, которые можно было бы перенести в модифицированный Оберон. Не только то, что относится к синтаксису. К примеру, из таких языков: Ада, Модула3, Zonnon, Objective-C, D, C#, Python
Тут такая штука... (всё сказанное далее IMHO)...
Оберон или Паскаль или Модула... никакой принципиальной разницы нет... даже Си, по большому счёту не так плох, как его малюют... Не надо делать "супер-язык"...
Так что вы предлагаете внести и/или изменить в Обероне, чтобы соответствовать вашей концепции? Никто не предлагает делать "супер-язык". Просто есть проблема - все С-языки - вцелом говно, но есть в них некоторые здравые мысли и удачные решения. Вот я и предлагаю рассмотреть, что можно было бы перенести в Оберон.
-
Так что вы предлагаете внести и/или изменить в Обероне, чтобы соответствовать вашей концепции? Никто не предлагает делать "супер-язык". Просто есть проблема - все С-языки - вцелом говно, но есть в них некоторые здравые мысли и удачные решения. Вот я и предлагаю рассмотреть, что можно было бы перенести в Оберон.
С точки зрения языка ничего особого добавлять не нужно... Язык программирования, с моей точки зрения, нужен для записи алгоритмов. Из того, что не принципиально, но удобно/полезно, я бы добавил обработку исключений, и может быть возможность создавать полноценные макросы, обрабатываемые на стадии предварительной компиляции (но это дело вкуса). Да, и конечно, вернул бы GoTo... для удобства записи алгоритмов... опять же :)
Что же касается среды разработки и рантайма... то это... отдельная большая тема...
-
Язык программирования, с моей точки зрения, нужен для записи алгоритмов. Из того, что не принципиально, но удобно/полезно, я бы добавил обработку исключений, и может быть возможность создавать полноценные макросы, обрабатываемые на стадии предварительной компиляции (но это дело вкуса). Да, и конечно, вернул бы GoTo... для удобства записи алгоритмов... опять же :)
Если так , то да - но он (хотите вы этого или нет) используется для описания систем в терминах своих конструкций.
1. Разумно добавить - инициализаторы (конструкторы) записей (и ввести декларированную инициализацию переменных нулями по умолчанию)
2. Изменить цикл REPEAT - что бы он работал в терминах условий продолжения
3. Снять дурацкое ограничение на типы возвращаемые функцией - должна уметь возвращать все что можно определить в языке (что бы человек работал с тем, что ему нужно)
4 Ну и вернуть как это сделано в Зонноне -read,write -для целей образования
5 Возможно ввести динамические строки
-
Но проблема в другом - для чего это (или кого).
-
Если так , то да - но он (хотите вы этого или нет) используется для описания систем в терминах своих конструкций.
Для описания систем в Обероне нет ничего... да. и не должно быть. Желательно иметь связь с "над-языком", но это можно делать и вне языковых конструкций Оберона.
1. Разумно добавить - инициализаторы (конструкторы) записей (и ввести декларированную инициализацию переменных нулями по умолчанию)
Строго говоря, при описании типа/структуры/класса может/должен задаваться шаблон инициализации. Всё, что не инициализируется шаблоном, должно инициализироваться значениями по умолчанию (нулями, в частном случае). Шаблоны инициализации удобны тем, что не нарушают инкапсуляции. Если я создаю новый класс, например, на основе некоторого класса, исходников которого у меня нет... то компилятор, просто дописывает к шаблону класса-предка, шаблон полей его наследника, получая, таким образом, полный шаблон инициализации класса-наследника.
2. Изменить цикл REPEAT - что бы он работал в терминах условий продолжения
То есть, loop?
3. Снять дурацкое ограничение на типы возвращаемые функцией - должна уметь возвращать все что можно определить в языке (что бы человек работал с тем, что ему нужно)
Не знаю... надо подумать... рассмотреть варианты с возвращением значения и ссылки.
4 Ну и вернуть как это сделано в Зонноне -read,write -для целей образования
Согласен.
5 Возможно ввести динамические строки
Не принципиально... для меня.
-
Если так , то да - но он (хотите вы этого или нет) используется для описания систем в терминах своих конструкций.
Для описания систем в Обероне нет ничего... да. и не должно быть. Желательно иметь связь с "над-языком", но это можно делать и вне языковых конструкций Оберона.
1. Разумно добавить - инициализаторы (конструкторы) записей (и ввести декларированную инициализацию переменных нулями по умолчанию)
Строго говоря, при описании типа/структуры/класса может/должен задаваться шаблон инициализации. Всё, что не инициализируется шаблоном, должно инициализироваться значениями по умолчанию (нулями, в частном случае). Шаблоны инициализации удобны тем, что не нарушают инкапсуляции. Если я создаю новый класс, например, на основе некоторого класса, исходников которого у меня нет... то компилятор, просто дописывает к шаблону класса-предка, шаблон полей его наследника, получая, таким образом, полный шаблон инициализации класса-наследника.
2. Изменить цикл REPEAT - что бы он работал в терминах условий продолжения
То есть, loop?
3. Снять дурацкое ограничение на типы возвращаемые функцией - должна уметь возвращать все что можно определить в языке (что бы человек работал с тем, что ему нужно)
Не знаю... надо подумать... рассмотреть варианты с возвращением значения и ссылки.
4 Ну и вернуть как это сделано в Зонноне -read,write -для целей образования
Согласен.
5 Возможно ввести динамические строки
Не принципиально... для меня.
0. Есть (например в секции TYPE CONST VAR, процедуры - как субалгоритмы, модули), но я чувствую что мы не понимаем друг друга, вы говорите про создание (проектирование) систем с нуля, я говорю про описание СУЩЕСТВУЮЩИХ систем в терминах ЯП. Тем не менее , для Вашего варианта в ЯП тоже есть средства- правда класс систем которых можно ЭФФЕКТИВНО описать средствами минималистического ЯП сильно ограничен (хотя я считаю , что попытки делать это ВРЕДНЫ).
2. Нет, речь идет об аналоге do while (из си).
5. А вот в этом и дело - что обо всем мы судим главным образом по себе :) это по поводу вашего пассажа об искаженном восприятии мира оберонцами в соседней ветки
-
Можно добавить Адский вывод типов (частично)
-
0. Есть (например в секции TYPE CONST VAR, процедуры - как субалгоритмы, модули), но я чувствую что мы не понимаем друг друга, вы говорите про создание (проектирование) систем с нуля, я говорю про описание СУЩЕСТВУЮЩИХ систем в терминах ЯП. Тем не менее , для Вашего варианта в ЯП тоже есть средства- правда класс систем которых можно ЭФФЕКТИВНО описать средствами минималистического ЯП сильно ограничен (хотя я считаю , что попытки делать это ВРЕДНЫ).
Система - она и есть система, и с нуля её создавать или на какой-то готовой основе... тоже не сильно принципиально (какая-то основа всегда есть...). Любая система, с точки зрения структуры, - это элементы и связи. Если элементы как-то можно описать структурами/классами, упаковать из в массивы или списки, то как описать связи? Как некоторые коллекции указателей на структуры?.. Но связи, как правило параметризованы... Что есть в ЯП для адекватного представления связей?.. Процедурные переменные?.. Функции-члены?.. Для простых случаев со статичными связями, как-то можно выкрутится, при динамичных связях всё это очень криво выглядит.
Далее. Если мы рассматриваем более одного уровня системы, то нужны декларации интерфейсов с последующей их проекцией на модули, описывающие/реализующие классы/объекты/структуры/переменные... Необходимо отслеживать реализацию интерфейсов (хотя бы на уровне заглушек-перехватчиков обращений). Наконец, надо контролировать полноту интерфейсов на основе их декомпозиции (иерархии интерфейсов). Что есть в ЯВУ для решения этой задачи?..
... и пр. и пр.
-
Хотелось бы примеров таких связей и описания их не на ЯВУ.
-
Система - она и есть система, и с нуля её создавать или на какой-то готовой основе... тоже не сильно принципиально (какая-то основа всегда есть...). Любая система, с точки зрения структуры, - это элементы и связи. Если элементы как-то можно описать структурами/классами, упаковать из в массивы или списки, то как описать связи? Как некоторые коллекции указателей на структуры?.. Но связи, как правило параметризованы... Что есть в ЯП для адекватного представления связей?.. Процедурные переменные?.. Функции-члены?.. Для простых случаев со статичными связями, как-то можно выкрутится, при динамичных связях всё это очень криво выглядит.
Далее. Если мы рассматриваем более одного уровня системы, то нужны декларации интерфейсов с последующей их проекцией на модули, описывающие/реализующие классы/объекты/структуры/переменные... Необходимо отслеживать реализацию интерфейсов (хотя бы на уровне заглушек-перехватчиков обращений). Наконец, надо контролировать полноту интерфейсов на основе их декомпозиции (иерархии интерфейсов). Что есть в ЯВУ для решения этой задачи?..
... и пр. и пр.
Так и я ВАМ ПРО ЭТО и говорю (КАК ПРАВИЛО ПРОБЛЕМА НЕ В КРИВОСТИ -А В ТОМ, ЧТО ОПИСАНИЕ СИСТЕМ НА ЯП ДОБАВЛЯЕТ НОВЫЕ СУЩНОСТИ И СВЯЗИ - УСЛОЖНЯЕТ РЕЗУЛЬТИРУЮЩУЮ СИСТЕМУ) - НО замечаю что ЕСТЬ классы СИСТЕМ которые ХОРОШО описываются ЯП - это ПРАКТИЧЕСКИ ВСЕ задачи ОБРАЗОВАТЕЛЬНОГО уровня.
-
Хотелось бы примеров таких связей и описания их не на ЯВУ.
Возьмите любую достаточно сложную модель из физики или математики - модель идеального газа... идеального кристалла... дифф. уравнения, интегралы по Риману..... - короче ВСЕ - но и общепринятое описание этих систем....
-
Хотелось бы примеров таких связей и описания их не на ЯВУ.
Возьмите любую достаточно сложную модель из физики или математики - модель идеального газа... идеального кристалла... дифф. уравнения, интегралы по Риману..... - короче ВСЕ - но и общепринятое описание этих систем....
Подозреваю что Александр имел ввиду что то более другое, ибо то что ты привел, на ЯВУ изобразить вообще не проблема.
-
Хотелось бы примеров таких связей и описания их не на ЯВУ.
Возьмите любую достаточно сложную модель из физики или математики - модель идеального газа... идеального кристалла... дифф. уравнения, интегралы по Риману..... - короче ВСЕ - но и общепринятое описание этих систем....
Подозреваю что Александр имел ввиду что то более другое, ибо то что ты привел, на ЯВУ изобразить вообще не проблема.
Кому то да , а кому и корова невеста...(я говорю про чистых кодеров)
-
Но вообще то я привел пример - систем со связями , которые описываются наитивным языком (не ЯП) - не более того, но и не менее
-
Нужно явно выделять стадии моделирования и проектирования, чего в "коровнике" ((с) DIzer) не понимают и не принимают... Однако и это ещё не всё... Если всё же стадии моделирования и проектирования обособляются, то становится понятно, что создавать надо не программу, а систему... но система не решает частных задач, она является основой... платформой для решения многих и разных (по классу) задач. А значит нужен принципиально другой подход... нужно моделировать и проектировать не задачу, а инструменты для решения задач. А это совсем иное... и средства совсем другие... то есть, языки программирования здесь... фиолетовы... нужны языки описания предметной области, как... среды конструирования, например.
Я не понимаю, с чего Вы взяли, что "не понимают и не принимают". Меня не меньше Вашего интересуют эти темы. Только я, например, не обсуждаю их направо и налево, потому что пока просто наживаю опыт и думаю... Мне далеко до Вас в этой тематике, что уж там... Я лучше почитаю и подумаю, чем буду городить "ещё один суперсистемный подход". Хочется не "ещё одного", а нащупать уникальный-оптимальный, при этом убедиться эмпирически в этой оптимальности (как в оптимальности Оберона на языковом уровне). На это нужны годы работы...
Я не раз пытался донести свою позицию: для решения интересных задач, на системном уровне, нужно, чтобы работа спорилась и кипела на уровне обычного программирования. А как ей спорится и кипеть, если программисты с улицы обученные не пойми где не пойми чему, пишут кто в лес, кто по дрова, делают ошибку к ошибке - и когда же им, бедным, думать об интересных задачах и участвовать в проектировании, если нужно дежучить очередной баг... Вот то, что мне может предложить рынок труда. Спасибо, не хочу. Как не хочет и Info21. Потому и сконцентрировались на несколько лет на безумно острой задаче разработки методов, способных подтянуть талантливых новичков до нужного уровня в программировании, чтобы как можно скорее включать их в интересные темы.
-
Насчет функционального программирования, если ввести, то как это может выглядеть в Обероне, чтобы вписаться в стиль и не быть убожеством, как в Делфи?
-
В язык -никак... ФП - это инструмент другого уровня. Более удалённый от вычислительной техники и имеющий более узкую сферу применения.
Применять же архитектурно, хотя бы те же ленивые вычисления, никто не мешает.
-
Насчет функционального программирования, если ввести, то как это может выглядеть в Обероне, чтобы вписаться в стиль и не быть убожеством, как в Делфи?
Что означает "убожество" -вы говорите об ущербности в их функциональности?
-
Я не раз пытался донести свою позицию: для решения интересных задач, на системном уровне, нужно, чтобы работа спорилась и кипела на уровне обычного программирования. А как ей спорится и кипеть, если программисты с улицы обученные не пойми где не пойми чему, пишут кто в лес, кто по дрова, делают ошибку к ошибке - и когда же им, бедным, думать об интересных задачах и участвовать в проектировании, если нужно дежучить очередной баг... Вот то, что мне может предложить рынок труда. Спасибо, не хочу. Как не хочет и Info21. Потому и сконцентрировались на несколько лет на безумно острой задаче разработки методов, способных подтянуть талантливых новичков до нужного уровня в программировании, чтобы как можно скорее включать их в интересные темы.
Так где они - такие программисты взращенные на "ниве" столь хорошего языка и системы - что -то не видно их , как не видно (по крайней мере 1 назад), так же как обсуждения "интересных" задач, а вот гонения инакомыслящих (под предлогом "очищения"), и рассуждений о "приматичности" природы человека (как оправдание несостоятельности идей) в избытке..
-
А как Вы их должны видеть?
Они должны приходить трындеть на форум?
Мне, действительно, непросто далось повышение КПД образовательного процесса (и своего КПД как преподавателя, потому что в плане методики, ориентированной на среднего студента, у меня долго были пробелы). Но сейчас я вижу на 3 курсе 15 человек из 3, которых на 4-м я смогу как-то задействовать на давно меня интересующих темах. И я, наконец, облегчённо вздыхаю :) "Поток" есть, "процесс пошёл".
По поводу некоторой раздражительности в модерировании на форумах... На самом деле, наличие субъектов, которые не ставят своей целью вложить усилия, а просто "перемыть кости Оберону", бесполезно. Это можно было бы терпеть, если бы это не стало так утомлять. Это реально просто утомительно - и ни даёт ни йоты пользы. Потому что все реальные проблемы Оберона мне лично известны не хуже Вас и других. Не хуже любого. Так же как вся тематика ЯП, инструментария, системного программирования. И на кой мне, например, слушать одно и то же нытьё.
Поэтому полезны на форуме две категории обсуждений - Оберонисто-конкретные, либо по другим темам: методы проектирования, другие системы и проч. При этом без всякого опостылевшего "сравнизма-г-низма".
-
А как Вы их должны видеть?
Они должны приходить трындеть на форум?
Мне, действительно, непросто далось повышение КПД образовательного процесса (и своего КПД как преподавателя, потому что в плане методики, ориентированной на среднего студента, у меня долго были пробелы). Но сейчас я вижу на 3 курсе 15 человек из 3, которых на 4-м я смогу как-то задействовать на давно меня интересующих темах. И я, наконец, облегчённо вздыхаю :) "Поток" есть, "процесс пошёл".
По поводу некоторой раздражительности в модерировании на форумах... На самом деле, наличие субъектов, которые не ставят своей целью вложить усилия, а просто "перемыть кости Оберону", бесполезно. Это можно было бы терпеть, если бы это не стало так утомлять. Это реально просто утомительно - и ни даёт ни йоты пользы. Потому что все реальные проблемы Оберона мне лично известны не хуже Вас и других. Не хуже любого. Так же как вся тематика ЯП, инструментария, системного программирования. И на кой мне, например, слушать одно и то же нытьё.
Поэтому полезны на форуме две категории обсуждений - Оберонисто-конкретные, либо по другим темам: методы проектирования, другие системы и проч. При этом без всякого опостылевшего "сравнизма-г-низма".
1. Все зависит от Вуза, потока, специальности, конечно, но по нашему вузу 3 из 15 МИНИМАЛЬНЫЙ набор ТОЛКОВЫХ студентов на группу - меньше не бывает, и эта константа не зависит от методики преподавания,- это люди которые могут переварить любую относительно внятную методу (в том числе и обучение на ББ) -достижением бы был ПРИРОСТ к этому числу (именно за счет методики).
2. И по этому вы причесали Губанова и AlexUsa?....
-
И да - хотел бы видеть - хотя бы бледную тень от http://it.mmcs.rsu.ru/forum?func=showcat&catid=27 (http://it.mmcs.rsu.ru/forum?func=showcat&catid=27) она бы показала что вы на правильном пути лучше всякой болтовни.
-
Хотелось бы примеров таких связей и описания их не на ЯВУ.
Собственно, любая система имеет два типа связей:- "Сильные" связи - это те связи, которые образуют элементы системы;
- "Слабые" связи - те связи, которые система устанавливает между своими элементами
Примеры "слабых" связей... Пожалуйста... На предприятии подсистемы/подразделения обмениваются ресурсами: сбыт получает деньги от финансовой подсистемы, закупает на них сырьё, комплектующие и др. материалы и передаёт их в производство, производство из этих материалов делает продукцию/оказывает услуги и передаёт её/их в сбыт, сбыт реализует продукцию/услуги, а деньги от реализации передаёт в финансовое подразделение... При этом связи могут динамически выстраиваться и меняться. Например, какие-то ресурсы предприятие закупало во-вне, а потом начало само производить для своего основного производства, а потом и для продажи/реализации, а другие ресурсы, наоборот, прекратили выпускать (не рентабельно, например) и стали закупать во-вне. Могут появляться новые подсистемы и образовывать новые связи, могут исчезать какие-то подсистемы и разрывать связи... Всё управление подсистемами, равно, как и связями, в руках пользователей.
Это частный случай "слабых" связей между подсистемами (элементами) системы.
-
Нужно явно выделять стадии моделирования и проектирования, чего в "коровнике" ((с) DIzer) не понимают и не принимают... Однако и это ещё не всё... Если всё же стадии моделирования и проектирования обособляются, то становится понятно, что создавать надо не программу, а систему... но система не решает частных задач, она является основой... платформой для решения многих и разных (по классу) задач. А значит нужен принципиально другой подход... нужно моделировать и проектировать не задачу, а инструменты для решения задач. А это совсем иное... и средства совсем другие... то есть, языки программирования здесь... фиолетовы... нужны языки описания предметной области, как... среды конструирования, например.
Я не понимаю, с чего Вы взяли, что "не понимают и не принимают". Меня не меньше Вашего интересуют эти темы. Только я, например, не обсуждаю их направо и налево, потому что пока просто наживаю опыт и думаю... Мне далеко до Вас в этой тематике, что уж там... Я лучше почитаю и подумаю, чем буду городить "ещё один суперсистемный подход". Хочется не "ещё одного", а нащупать уникальный-оптимальный, при этом убедиться эмпирически в этой оптимальности (как в оптимальности Оберона на языковом уровне). На это нужны годы работы...
Угу... Вся теория систем укладывается на нескольких страничках... У Вас получается, как в к/ф "Формула Любви": — Степан! У гостя карета сломалась.
— Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну… За… Сделаем и за два.
— А за пять дней?
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!
— Бери помощников, но чтобы не раньше!
Я не раз пытался донести свою позицию: для решения интересных задач, на системном уровне, нужно, чтобы работа спорилась и кипела на уровне обычного программирования. А как ей спорится и кипеть, если программисты с улицы обученные не пойми где не пойми чему, пишут кто в лес, кто по дрова, делают ошибку к ошибке - и когда же им, бедным, думать об интересных задачах и участвовать в проектировании, если нужно дежучить очередной баг... Вот то, что мне может предложить рынок труда. Спасибо, не хочу. Как не хочет и Info21.
Как я понимаю, Вам надо несколько Ермаковых... Ну, поставьте компьютер на трюмо, и будет Вам щастье... (Н-да, я ничуть не жалею, что моё мнение о Вас поменялось... всё равно оно лучше, чем то, что приходится... лицезреть).
Потому и сконцентрировались на несколько лет на безумно острой задаче разработки методов, способных подтянуть талантливых новичков до нужного уровня в программировании, чтобы как можно скорее включать их в интересные темы.
До "спиц" Вы ещё не скоро доберётесь... IMHO.
-
Если всё же стадии моделирования и проектирования обособляются, то становится понятно, что создавать надо не программу, а систему... но система не решает частных задач, она является основой... платформой для решения многих и разных (по классу) задач.
Ох пропустил пассаж... простите, если не трудно, коротко что вы понимаете под стадией моделирования? (есть подозрение, что мы имеем ввиду разные вещи)
-
Поэтому полезны на форуме две категории обсуждений - Оберонисто-конкретные, либо по другим темам: методы проектирования, другие системы и проч. При этом без всякого опостылевшего "сравнизма-г-низма".
Принцип инквизиции сформулирован... судилища начались... Тьфу...
-
Если всё же стадии моделирования и проектирования обособляются, то становится понятно, что создавать надо не программу, а систему... но система не решает частных задач, она является основой... платформой для решения многих и разных (по классу) задач.
Ох пропустил пассаж... простите, если не трудно, коротко что вы понимаете под стадией моделирования? (есть подозрение, что мы имеем ввиду разные вещи)
Стадия анализа и моделирования... Перед тем, как создать нечто новое, необходимо сформировать его образ. Конструктор-дизайнер набрасывает общий вид будущей машины, архитектор рисует эскиз строения, писатель обрисовывает будущую книгу... программист участвует в формировании технического задания... Моделирование рождается из анализа требований, ресурсных возможностей. После моделирования идёт стадия проектирования, потом планирования, реализации, эксплуатации и... снова анализ, моделирование... И так по восходящей.
-
Если всё же стадии моделирования и проектирования обособляются, то становится понятно, что создавать надо не программу, а систему... но система не решает частных задач, она является основой... платформой для решения многих и разных (по классу) задач.
Ох пропустил пассаж... простите, если не трудно, коротко что вы понимаете под стадией моделирования? (есть подозрение, что мы имеем ввиду разные вещи)
Стадия анализа и моделирования... Перед тем, как создать нечто новое, необходимо сформировать его образ. Конструктор-дизайнер набрасывает общий вид будущей машины, архитектор рисует эскиз строения, писатель обрисовывает будущую книгу... программист участвует в формировании технического задания... Моделирование рождается из анализа требований, ресурсных возможностей. После моделирования идёт стадия проектирования, потом планирования, реализации, эксплуатации и... снова анализ, моделирование... И так по восходящей.
Спасибо, так и думал... действительно у слова есть 2 различных значения ,одно из них вы описали только что - почти полный эквивалент проектирования, но есть еще и второе - имитация работы системы с ЗАДАННЫМИ параметрами - стандартное определение в естественных науках (то что я использую по умолчанию (если из контекста не ясно иное)) - эквивалент работы программы...
-
Поэтому полезны на форуме две категории обсуждений - Оберонисто-конкретные, либо по другим темам: методы проектирования, другие системы и проч. При этом без всякого опостылевшего "сравнизма-г-низма".
Принцип инквизиции сформулирован... судилища начались... Тьфу...
Они и не кончались.. нормальная дифференциация по цвету штанов (простая, удобная, и главное "оберонисто -конкретная") - полная киндза -дза с эцилопами и г-ном Боже...
-
Спасибо, так и думал... действительно у слова есть 2 различных значения ,одно из них вы описали только что - почти полный эквивалент проектирования, но есть еще и второе - имитация работы системы с ЗАДАННЫМИ параметрами - стандартное определение в естественных науках (то что я использую по умолчанию (если из контекста не ясно иное)) - эквивалент работы программы...
Проектирование - это совсем другое... Проектирование начинается тогда, когда понятна суть будущего продукта... когда найдены основные решения, когда определены базовые протоколы...
-
Alexus, чтобы вы предложили сделать в Обероне, чтобы соответствовать вашей концепции интерфейсов?
-
Спасибо, так и думал... действительно у слова есть 2 различных значения ,одно из них вы описали только что - почти полный эквивалент проектирования, но есть еще и второе - имитация работы системы с ЗАДАННЫМИ параметрами - стандартное определение в естественных науках (то что я использую по умолчанию (если из контекста не ясно иное)) - эквивалент работы программы...
Проектирование - это совсем другое... Проектирование начинается тогда, когда понятна суть будущего продукта... когда найдены основные решения, когда определены базовые протоколы...
А это у меня входит в проектирование - я трактую его в обобщенном смысле, и стараюсь использовать для этого этапа термин "построение системы" как некоторого множества моделей и описания взаимодействия между ними, реакции системы по отношению к внешним параметрам... в более узком смысле, если речь идет об одной или небольшом числе моделей - о "построении (модификации существующей) модели" , а термин "моделирование" в этом контексте - стараюсь не использовать.
-
Моделирование рождается из анализа требований, ресурсных возможностей.
Вы хотели сказать "Модель рождается [...]". Если всё же "моделирование", то не могли бы вы этот момент описать подробнее?
-
Проектирование начинается [...], когда определены базовые протоколы...
А разве протокол не является предметом проектирования?
-
Предлагаю кратко рассмотреть удачные идеи в других языках, которые можно было бы перенести в модифицированный Оберон. Не только то, что относится к синтаксису. К примеру, из таких языков: Ада, Модула3, Zonnon, Objective-C, D, C#, Python
Вот тут еще было похожее обсуждение: http://oberspace.dyndns.org/index.php/topic,26.0.html
-
Проектирование начинается [...], когда определены базовые протоколы...
А разве протокол не является предметом проектирования?
Он может им являться = а может быть и задан. Вообще давать определение систем произвольной сложности - путем перечисления допустимых сущностей и связей -дело неблагодарное по этому мое сообщение следует рассматривать как иллюстративное (да , думаю, что термин проектирование - в моем применении неудачен, в особенности если имеешь дело с инженерами - у них он вызывает рефлекс аналогичный, тому , который у меня идет от слова моделирование).
-
Предлагаю кратко рассмотреть удачные идеи в других языках, которые можно было бы перенести в модифицированный Оберон. Не только то, что относится к синтаксису. К примеру, из таких языков: Ада, Модула3, Zonnon, Objective-C, D, C#, Python
Вот тут еще было похожее обсуждение: http://oberspace.dyndns.org/index.php/topic,26.0.html
А я говорил об этом Vartovyj
-
А разве протокол не является предметом проектирования?
Он может им являться = а может быть и задан. Вообще давать определение систем произвольной сложности - путем перечисления допустимых сущностей и связей -дело неблагодарное по этому мое сообщение следует рассматривать как иллюстративное (да , думаю, что термин проектирование - в моем применении неудачен, в особенности если имеешь дело с инженерами - у них он вызывает рефлекс аналогичный, тому , который у меня идет от слова моделирование).
-
Ну пусть даже и задан. Ведь вообще как таковой он из ничего не взялся? Наверное, был создан в рамках другой системы. Если избавиться от цитаты как контекста и перенести контекст в сам вопрос, то можно спросить у alexus-а так: почему Вы относите протокол к анализу и моделированию, а не к проектированию?
-
относите протокол
То есть, создание протокола.
-
Ну пусть даже и задан. Ведь вообще как таковой он из ничего не взялся? Наверное, был создан в рамках другой системы. Если избавиться от цитаты как контекста и перенести контекст в сам вопрос, то можно спросить у alexus-а так: почему Вы относите протокол к анализу и моделированию, а не к проектированию?
И что вас смущает? если вы строите дом из кучи кирпичей и конструкций лежащих на строительной площадке - какая вам разница какой завод их произвел?
-
Alexus, чтобы вы предложили сделать в Обероне, чтобы соответствовать вашей концепции интерфейсов?
Дело не в Обероне. Сегодня интерфейсы, как правило, определяются на уровне компонентов или программных модулей. Но более правильно было бы определять их на уровне системы, когда её поделили по уровням. Поскольку Оберон нацелен на создание программ, и никаких системных уровней он не поддерживает, в принципе, то он не может соответствовать "моей" концепции интерфейсов.
Если рассуждать с позиций системы... В соответствии с решаемыми задачами, система разделена на уровни. Каждый вышестоящий уровень общается с нижестоящим (равно, как и наоборот) через интерфейсы. Если мы специфицировали интерфейсы, то можно начинать их реализацию, и язык программирования + среда разработки должны нам показывать, какие интерфейсы и как реализованы (или ещё не реализованы, но распределены по классам/сущностям, или даже не распределены и требуют распределения... то есть, стадия проектирования данного уровня системы ещё не завершена). При этом проектирование может/должно происходить в одной среде разработки, а реализация, на том же Обероне. Тогда среда разработки Оберон (или другого ЯП) должна понимать спецификации, полученные из среды проектирования, помнить версию каждого специфицированного элемента и отличия новой версии от предыдущей, включая источник изменений.
Декларация интерфейсов по структуре/по сути практически не отличается от тех интерфейсов, которые сегодня поддерживаются ЯП. Но я повторю, что дело не в том, как объявлять интерфейсы, а в том, как они образуются. И, следовательно, если в Оберон будет поддержка интерфейсов, то это хорошо, но это не сделает язык более системным, чем он есть сейчас.
-
Дело не в Обероне. Сегодня интерфейсы, как правило, определяются на уровне компонентов или программных модулей. Но более правильно было бы определять их на уровне системы, когда её поделили по уровням. Поскольку Оберон нацелен на создание программ, и никаких системных уровней он не поддерживает, в принципе, то он не может соответствовать "моей" концепции интерфейсов.
Зависит от системы (скажем так, я в основном работаю с системами (несложными архитектурно), требующими "разработки" предметной области - тут хочешь не хочешь а приходится разрабатывать ее в терминах наитивного языка, потом отображать на структуры и алгоритмы, и только после этого переводить получившееся хозяйство на целевой ЯП.), но если искомую систему можно определить как набор программных компонент четкими связями между ними - почему бы и нет.
-
Проектирование - это совсем другое... Проектирование начинается тогда, когда понятна суть будущего продукта... когда найдены основные решения, когда определены базовые протоколы...
А это у меня входит в проектирование - я трактую его в обобщенном смысле, и стараюсь использовать для этого этапа термин "построение системы" как некоторого множества моделей и описания взаимодействия между ними, реакции системы по отношению к внешним параметрам... в более узком смысле, если речь идет об одной или небольшом числе моделей - о "построении (модификации существующей) модели" , а термин "моделирование" в этом контексте - стараюсь не использовать.
Построение системы включает в себя 4 этапа:
- Анализ и моделирование;
- Проектирование;
- Планирование;
- Разработка.
Каждый этап имеет свою специфику и, соответственно, предъявляет разные требования к тем, кто их выполняет. Скажем, моделирует дизайнер, а проектирует конструктор, планирует деятельность - плановик, а выполняет - слесарь. В программировании точно также, хотя часто все стадии выполняет один и тот же человек/одна и та же команда. К сожалению и результаты... бывают далеки от хороших.
Чем выше требования к внешнему виду и эргономике, тем большая потребность в хороших дизайнерах. Если требования к внешнему виду не специфицированы, то... моделирование внешнего вида может быть пропущено. При разработке больших (многоуровневых) технических систем дизайнер должен не только и не столько заниматься внешним видом, сколько компоновкой основных агрегатов, устойчивостью конструкции, основным принципам её функционирования/принципиальной конфигурации системы, если говорить о программных системах...
Проектирование - это более рациональная стадия, где основой является декомпозиция... вплоть до последнего болта... На этой стадии модель разбирается на мельчайшие составные части, для которых, если необходимо, определяются рабочие и максимальные нагрузки, выполняются расчёты и, наконец, выполняются чертежи (в CAD-системе, например). В программных системах при проектировании определяются все внутренние и внешние протоколы, интерфейсы, иерархии классов/наборы сущностей/структуры баз данных, выбираются алгоритмы и пр.
Детально зная, что нам нужно реализовать, примерно определив затраты времени и квалификационные требования, мы можем спланировать работу команды, каждого человека... потребности в тех или иных инструментах, сервисах и пр.
Ну, про стадию реализации все и так знают... :)
-
Построение системы включает в себя 4 этапа:
- Анализ и моделирование;
- Проектирование;
- Планирование;
- Разработка.
......
Это не вызывает никаких возражений, я говорю вам, что в ряде случаев эту схему можно упростить (на свой страх и риск) - и не всегда результаты будут плачевны - хотя должен признать, что пренебрежение этапом планирования достаточно часто било по моим интересам...
-
Моделирование рождается из анализа требований, ресурсных возможностей.
Вы хотели сказать "Модель рождается [...]". Если всё же "моделирование", то не могли бы вы этот момент описать подробнее?
Моделирование, как стадия разработки, рождается из анализа требований. Модель - это результат моделирования. Так что оба варианта правильны, только акценты смещаются, я говорю о моделировании, как о специфической деятельности, Вы переносите акцент на результат.
В качестве примера... Посмотрите на смартфоны. Они относительно недавно появились на рынке и активно развиваются. Фирмы-проектировщики (отметьте, не фирмы-производители!) следят за тем, как воспринимаются те или иные новшества в каждой новой модели смартфона (при этом они отслеживают не только свои модели, но и модели конкурентов). Каждое удачное новшество закрепляется в последующих моделях... Но это только "одна сторона медали", с другой стороны они следят за новыми изделиями: процессорами, контроллерами, разного рода датчиками и сенсорами, памятью, материалами для корпуса, стеклами и пр. Вся эта информация переваривается в головах тех, кто занимается моделированием и... они "выдают на гора" новые модели с улучшенными старыми и совсем новыми возможностями смартфонов. В программировании эти процессы происходят сходным образом... Мы смотрим, насколько удобны в использовании наши программы, что-то дорабатываем в них... и параллельно обсуждаем появление новых инструментов, оцениваем их применимость для наших задач... И в конечном итоге пишем более функциональные и удобные программы с меньшими издержками... (ну, в идеале...) :)
-
Ну пусть даже и задан. Ведь вообще как таковой он из ничего не взялся? Наверное, был создан в рамках другой системы. Если избавиться от цитаты как контекста и перенести контекст в сам вопрос, то можно спросить у alexus-а так: почему Вы относите протокол к анализу и моделированию, а не к проектированию?
Протокол может определяться на стадии моделирования, а доопределяться, в виде формальных (однозначных) описаний на стадии проектирования. Приведу аналогию. Дизайнер соединил дом и хозяйственную постройку переходом. Смотрится красиво и удобно: в холодное время года/суток можно перейти из одного здания в другое не надевая тёплую одежду и обувь. Это стадия моделирования. Проектировщики описали (чертежами) сам переход, и в него "втолкнули" инженерные коммуникации: электричество, отопление и т.п. Это стадия проектирования.
Точно также в программной системе, дизайнер определил то, как будут взаимодействовать сущности, не вникая в детали, не расписывая их до байта и бита... А проектировщик потом должен будет сделать полную спецификацию протокола взаимодействия.
Протоколы могут быть внешними. Например, ток подаётся под определённым напряжение, определёной частоты и силы. И все внутренние сущности должны быть ориентированы на работу по этому протоколу. Точно также мы используем при программировании внешний протокол, например, TCP/IP и должны ему следовать.
-
Дело не в Обероне. Сегодня интерфейсы, как правило, определяются на уровне компонентов или программных модулей. Но более правильно было бы определять их на уровне системы, когда её поделили по уровням. Поскольку Оберон нацелен на создание программ, и никаких системных уровней он не поддерживает, в принципе, то он не может соответствовать "моей" концепции интерфейсов.
Зависит от системы (скажем так, я в основном работаю с системами (несложными архитектурно), требующими "разработки" предметной области - тут хочешь не хочешь а приходится разрабатывать ее в терминах наитивного языка, потом отображать на структуры и алгоритмы, и только после этого переводить получившееся хозяйство на целевой ЯП.), но если искомую систему можно определить как набор программных компонент четкими связями между ними - почему бы и нет.
Да, конечно. Для реализации одно/двух-уровневой системы не надо городить протоколы и модели, вполне можно воспользоваться тем, что есть.
-
Построение системы включает в себя 4 этапа:
- Анализ и моделирование;
- Проектирование;
- Планирование;
- Разработка.
......
Это не вызывает никаких возражений, я говорю вам, что в ряде случаев эту схему можно упростить (на свой страх и риск) - и не всегда результаты будут плачевны - хотя должен признать, что пренебрежение этапом планирования достаточно часто било по моим интересам...
Использование стадий разработки - это вопрос времени... и культуры (не этики и эстетики, а культуры работы). Я тоже не всегда прорабатываю все стадии так, как нужно... как правило из-за лени... с верой в авось... :)
-
Использование стадий разработки - это вопрос времени... и культуры (не этики и эстетики, а культуры работы). Я тоже не всегда прорабатываю все стадии так, как нужно... как правило из-за лени... с верой в авось... :)
Да нет , я по большей части , из - за желания
1. развить интуицию
2. попасть пальцем в небо
3. ну а лень - известный двигатель прогресса.
И отношусь к этому спокойно - один черт за все приходится платить самому...
-
Нужен ли CASE OF, если есть IF ELSIF?
DO WHILE вместо REPEAT UNTIL тоже хорошая идея упрощения синтаксиса.
-
CASE в последнем обероне определён для подряд идущих целых чисел и должен работать существенно быстрее чем цепочка ELSIF по тем же самым числам поскольку должен делать переход сразу в нужное место (это по сути параметризованный целым числом goto).
CASE для не чисел или для не подряд идущих чисел (короче, если нельзя его соптимизировать в прямой переход) не нужен ибо не будет быстрее того же самого ELSIF.
-
DO WHILE вместо REPEAT UNTIL синтаксиса не упрощает, а лишь уменьшает лексику на два слова.
-
CASE в последнем обероне определён для подряд идущих целых чисел и должен работать существенно быстрее чем цепочка ELSIF по тем же самым числам поскольку должен делать переход сразу в нужное место (это по сути параметризованный целым числом goto).
Ну, собственно современные и не очень компиляторы цепочку соответствующих if .. else if также оптимизируют таблицей переходов. То есть код генерируется идентичный case'у. Это очень простая и древняя оптимизация.
То есть для чего-то такого:
int main() {
int i = getchar();
if (i==1) i++;
else if (i==2) i--;
putc(i);
return 0;
}
Получается вот такое:
define i32 @main() nounwind uwtable {
%1 = tail call i32 (...)* @getchar() nounwind
switch i32 %1, label %4 [
i32 1, label %2
i32 2, label %3
]
; <label>:2 ; preds = %0
br label %4
; <label>:3 ; preds = %0
br label %4
; <label>:4 ; preds = %3, %2, %0
%i.0 = phi i32 [ 2, %2 ], [ 1, %3 ], [ %1, %0 ]
%5 = tail call i32 (...)* @putc(i32 %i.0) nounwind
ret i32 0
}
declare i32 @getchar(...) nounwind
declare i32 @putc(...)
-
Я бы убрал CASE. Для частных случаев можно определить решение в стандартной библиотеке.
Остается лишь навороченный FOR...(обсуждали на соседнем форуме), IF->ELSIF..., WHILE<->DO
-
Я бы убрал CASE. Для частных случаев можно определить решение в стандартной библиотеке.
Остается лишь навороченный FOR...(обсуждали на соседнем форуме), IF->ELSIF..., WHILE<->DO
Если смотреть чисто технически, то CASE это просто сахарок для некоторых частных случаев + возможность компиляторщику не заниматься анализом if'ов для оптимизации неких тривиальных случаев.
Если же смотреть с точки зрения пользователя (то есть программиста), то CASE для этих самых частных случаев существенно читабельней и понимабельней (не надо всматриваться в условия ifов). То есть смысл в CASE таки есть.
-
Если же смотреть с точки зрения пользователя (то есть программиста), то CASE для этих самых частных случаев существенно читабельней и понимабельней (не надо всматриваться в условия ifов). То есть смысл в CASE таки есть.
Согласен. Это как foreach против for. Да, это частный случай. Более ограниченный, но и более читабельный/выразительный для соответствующих ситуаций.
-
DO WHILE вместо REPEAT UNTIL синтаксиса не упрощает, а лишь уменьшает лексику на два слова.
оспода, конечно дело не лексике - а в каких терминах вы формулируете условия выполнения цикла... либо while (пока выполняется) либо until- РЕАЛЬНАЯ проблема у новичков - в том, что что в первом случае поощряется формулировка в терминах "продолжения" во втором в терминах "окончания"
-кстати у меня есть ощущение что это есть проблема ИСКЛЮЧИТЕЛЬНО неанглоязычных....
-
Кстати , господа - блиц - мне интересно в каких терминах вы предпочитаете формулировать цикл ( продолжения или окончания) - скажу честно, я , лично почему - то в большинстве случаев формулирую условие в терминах окончания... Зы конечно продолжения , простите.... :)
-
Второй момент, связка
WHILE A DO
DO
............
WHILE B;
END;
записанная по правилам Оберона выглядит ИМХО коряво...
-
Если смотреть чисто технически, то CASE это просто сахарок для некоторых частных случаев + возможность компиляторщику не заниматься анализом if'ов для оптимизации неких тривиальных случаев.
А может наоборот if - сахарок для частного случая?
CASE cond OF
|TRUE: stmt1
|FALSE: stmt2
END
-
Если смотреть чисто технически, то CASE это просто сахарок для некоторых частных случаев + возможность компиляторщику не заниматься анализом if'ов для оптимизации неких тривиальных случаев.
А может наоборот if - сахарок для частного случая?
CASE cond OF
|TRUE: stmt1
|FALSE: stmt2
END
if да, но не if … elif … else. Хотя конечно можно вложенных кейсов нагородить. Да что там - и if и case можно убрать оставив только while! :-)
PS.Вообще в функциональщине обычно if в оберонгвском виде отсутствует. Там именно расширенный паттернматчингом case.
-
А может наоборот if - сахарок для частного случая?
Думаю, что нет. Если в обощённом IF используются неоднородные условия, то его нельзя преобразовать в CASE. Например, такой:
if a = 1 then ... elsif b = 2 then ... end;
-
if да, но не if … elif … else. Хотя конечно можно вложенных кейсов нагородить. Да что там - и if и case можно убрать оставив только while! :-)
Можно и гланды через зад удалять. Вопрос - ЗАЧЕМ?
-
Имхо CASE на сахар не очень тянет, так как кострукция достаточно громоздкая и неэстетичная.
-
Думаю, что нет. Если в обощённом IF используются неоднородные условия, то его нельзя преобразовать в CASE. Например, такой:
if a = 1 then ... elsif b = 2 then ... end;
А у нас супер-case:)
case true of a = 1: ... | b = 2: ... end;
-
В общем, не надо толкать Оберон в трясину Тьюринга (http://ru.wikipedia.org/wiki/%D0%A2%D1%8C%D1%8E%D1%80%D0%B8%D0%BD%D0%B3%D0%BE%D0%B2%D1%81%D0%BA%D0%B0%D1%8F_%D1%82%D1%80%D1%8F%D1%81%D0%B8%D0%BD%D0%B0), он и так стоит на самом краю.
-
В общем, не надо толкать Оберон в трясину Тьюринга (http://ru.wikipedia.org/wiki/%D0%A2%D1%8C%D1%8E%D1%80%D0%B8%D0%BD%D0%B3%D0%BE%D0%B2%D1%81%D0%BA%D0%B0%D1%8F_%D1%82%D1%80%D1%8F%D1%81%D0%B8%D0%BD%D0%B0), он и так стоит на самом краю.
Никто не толкает, народ это, того... развлекается , и потом элемент творчества...
-
А как Вы их должны видеть?
Они должны приходить трындеть на форум?
Мне, действительно, непросто далось повышение КПД образовательного процесса (и своего КПД как преподавателя, потому что в плане методики, ориентированной на среднего студента, у меня долго были пробелы). Но сейчас я вижу на 3 курсе 15 человек из 3, которых на 4-м я смогу как-то задействовать на давно меня интересующих темах. И я, наконец, облегчённо вздыхаю :) "Поток" есть, "процесс пошёл".
По поводу некоторой раздражительности в модерировании на форумах... На самом деле, наличие субъектов, которые не ставят своей целью вложить усилия, а просто "перемыть кости Оберону", бесполезно. Это можно было бы терпеть, если бы это не стало так утомлять. Это реально просто утомительно - и ни даёт ни йоты пользы. Потому что все реальные проблемы Оберона мне лично известны не хуже Вас и других. Не хуже любого. Так же как вся тематика ЯП, инструментария, системного программирования. И на кой мне, например, слушать одно и то же нытьё.
Поэтому полезны на форуме две категории обсуждений - Оберонисто-конкретные, либо по другим темам: методы проектирования, другие системы и проч. При этом без всякого опостылевшего "сравнизма-г-низма".
1. Все зависит от Вуза, потока, специальности, конечно, но по нашему вузу 3 из 15 МИНИМАЛЬНЫЙ набор ТОЛКОВЫХ студентов на группу - меньше не бывает, и эта константа не зависит от методики преподавания,- это люди которые могут переварить любую относительно внятную методу (в том числе и обучение на ББ) -достижением бы был ПРИРОСТ к этому числу (именно за счет методики).
2. И по этому вы причесали Губанова и AlexUsa?....
1. Следует читать "15 из 30". Я сам не верил, что можно иметь больше 10, которые хоть как-то шевелятся. Но вот сочетание хорошей группы и методики - даёт...
2. Alexus ушёл сам. Увидев, что иногда сообщения попадают под "перекройку". Его это не устраивает - его право. У меня не было с ним никаких разногласий и споров, как я уже сказал (хотя он и, кажется, до сих пор убеждён, что показать более производительный код - это было значимое возражение на мой пример, а не оффтоп). Губанов ушёл за развязанную им войну с Info21. Он сознательно устроил "кровавую бойню" с безусловным нарушением правил (руганью и проч.). Я прекрасно понимаю, что он шёл "ва-банк", желая расставить все точки над i в своих отношениях с Info21. Его право делать это в ЛС. За публичное выяснение отношений не забанить было невозможно. Как мы должны были действовать по отношению к нему? Позвонить главному психотерапевту всех обиженных тов. Веселовскому с просьбой "забрать пациента в палату к себе на форум и дать валерьянки"? :) К Alexus-у вообще никаких действий не предпринималось (кроме оперативных, при групповых операциях в конкретных ветках), так как претензий к нему не было.
Хватит уже фальсифицировать историю. Вас-то в своё время банили из-за невозможности конструктивно общаться и нежелании "закрыть кран" тех претензий к Оберонам, на которые многократно был дан ответ - и вопрос по ним можно было считать исчерпанным.
-
Если в обощённом IF используются неоднородные условия, то его нельзя преобразовать в CASE. Например, такой:
if a = 1 then ... elsif b = 2 then ... end;
А у нас супер-case:)
case true of a = 1: ... | b = 2: ... end;
Так этот супер-case и не case вовсе :)
У настоящего case`а метки выбора исключают друг друга, а у Вас - нет. Условия a = b и b = 2 могут быть оба true. Возможно, Вы подразумеваете приоритет проверки меток. Но тогда результат может зависеть от того, в каком порядке они (метки) перечислены.
-
Так этот супер-case и не case вовсе :)
У настоящего case`а метки выбора исключают друг друга, а у Вас - нет.
А у меня case Дейкстры. ;)
-
А у меня case Дейкстры. ;)
А сам Дейкстра был в курсе, что есть такой оператор? ;)
-
Губанов ушёл за развязанную им войну с Info21. Он сознательно устроил "кровавую бойню" с безусловным нарушением правил (руганью и проч.). Я прекрасно понимаю, что он шёл "ва-банк", желая расставить все точки над i в своих отношениях с Info21. Его право делать это в ЛС. За публичное выяснение отношений не забанить было невозможно. Как мы должны были действовать по отношению к нему?
Илья, у тебя порча памяти. Всё было наоборот. Это info21 после того как опозорился, вчистую продувши спор про Старикова, записал меня в мракобесы и принялся со мной бороться. У тебя и Рюмшина пойти против info21 кишка тонка, поэтому забанили меня, а не его.
-
А как Вы их должны видеть?
Они должны приходить трындеть на форум?
Мне, действительно, непросто далось повышение КПД образовательного процесса (и своего КПД как преподавателя, потому что в плане методики, ориентированной на среднего студента, у меня долго были пробелы). Но сейчас я вижу на 3 курсе 15 человек из 3, которых на 4-м я смогу как-то задействовать на давно меня интересующих темах. И я, наконец, облегчённо вздыхаю :) "Поток" есть, "процесс пошёл".
По поводу некоторой раздражительности в модерировании на форумах... На самом деле, наличие субъектов, которые не ставят своей целью вложить усилия, а просто "перемыть кости Оберону", бесполезно. Это можно было бы терпеть, если бы это не стало так утомлять. Это реально просто утомительно - и ни даёт ни йоты пользы. Потому что все реальные проблемы Оберона мне лично известны не хуже Вас и других. Не хуже любого. Так же как вся тематика ЯП, инструментария, системного программирования. И на кой мне, например, слушать одно и то же нытьё.
Поэтому полезны на форуме две категории обсуждений - Оберонисто-конкретные, либо по другим темам: методы проектирования, другие системы и проч. При этом без всякого опостылевшего "сравнизма-г-низма".
1. Все зависит от Вуза, потока, специальности, конечно, но по нашему вузу 3 из 15 МИНИМАЛЬНЫЙ набор ТОЛКОВЫХ студентов на группу - меньше не бывает, и эта константа не зависит от методики преподавания,- это люди которые могут переварить любую относительно внятную методу (в том числе и обучение на ББ) -достижением бы был ПРИРОСТ к этому числу (именно за счет методики).
2. И по этому вы причесали Губанова и AlexUsa?....
1. Следует читать "15 из 30". Я сам не верил, что можно иметь больше 10, которые хоть как-то шевелятся. Но вот сочетание хорошей группы и методики - даёт...
2. Alexus ушёл сам. Увидев, что иногда сообщения попадают под "перекройку". Его это не устраивает - его право. У меня не было с ним никаких разногласий и споров, как я уже сказал (хотя он и, кажется, до сих пор убеждён, что показать более производительный код - это было значимое возражение на мой пример, а не оффтоп). Губанов ушёл за развязанную им войну с Info21. Он сознательно устроил "кровавую бойню" с безусловным нарушением правил (руганью и проч.). Я прекрасно понимаю, что он шёл "ва-банк", желая расставить все точки над i в своих отношениях с Info21. Его право делать это в ЛС. За публичное выяснение отношений не забанить было невозможно. Как мы должны были действовать по отношению к нему? Позвонить главному психотерапевту всех обиженных тов. Веселовскому с просьбой "забрать пациента в палату к себе на форум и дать валерьянки"? :) К Alexus-у вообще никаких действий не предпринималось (кроме оперативных, при групповых операциях в конкретных ветках), так как претензий к нему не было.
Хватит уже фальсифицировать историю. Вас-то в своё время банили из-за невозможности конструктивно общаться и нежелании "закрыть кран" тех претензий к Оберонам, на которые многократно был дан ответ - и вопрос по ним можно было считать исчерпанным.
1. 15 -из 30 это по нашим меркам ОЧЕНЬ МНОГО -средняя группа на первом курсе 25 чел. после первого, чудо если останется более 20,методика не причем - банально, за "информатику и программирование" у нас с 1 курса не выгоняют (да и вообще стараемся не выгонять - просто ТРЕБУЕМАЯ для усвоения материала степень развития интеллекта учащихся не соответствует той , которую они имеют после школы), третьему курсу остается 15-18... -из них 5-8 тех кто изображает подобие активности, с 5-10 можно пользуясь вашей терминологией "делать хоть что-то". НУ А С ТЕМИ о ком говорю Я можно делать ВСЕ и в любой области (не обязательно программирование) -все упирается в степень их личного интереса (а вот это уже вопрос из категории решаемых).
2.Я не говорил, что его (их) выгоняли- я использовал термин "причесали"- ущемили их права только за то , что они посмели высказаться НЕТ не против, а недостаточно "оберонисто". По поводу того во что это вылилось - это проблемы AlexUS a и С. Губанова, точнее их выбор.
-
Там какие-то тулзы недоступны. Оно вообще винду "partial support". Тем не менее это не мешало моим экспериментам на винде.
Вчера скачал llvm3.0. Собралось сразу (VS10), никаких плясок с бубном - пришлось только поставить cmake (виндовый инсталлятор есть) и натравить его на корень исходников. Собралось все, включая какие-то примеры.
P.S. Вот только готовых бинарей для винды на сайте не было. Не знаю, может у них там какие политические заморочки...
-
Вариант синтаксиса без end:
module ProgramPattern;
import Texts, Oberon;
w: Texts.Writer;
copy(r: Texts.Reader);
ch: char;
Texts.Read(r, ch);
while ~r.eot do Texts.Write(w, ch); Texts.Read(r, ch)
/while
/copy
SomeCommand*;
r: Texts.Reader;
Texts.OpenReader(r, Oberon.This.text, Oberon.Par.pos);
copy(r, w); Texts.Append(Oberon.Log, w.buf)
/SomeCommand;
Texts.OpenWriter(w)
/ProgramPattern.
-
Вариант синтаксиса без end:
module ProgramPattern;
import Texts, Oberon;
w: Texts.Writer;
copy(r: Texts.Reader);
ch: char;
Texts.Read(r, ch);
while ~r.eot do Texts.Write(w, ch); Texts.Read(r, ch)
/while
/copy
SomeCommand*;
r: Texts.Reader;
Texts.OpenReader(r, Oberon.This.text, Oberon.Par.pos);
copy(r, w); Texts.Append(Oberon.Log, w.buf)
/SomeCommand;
Texts.OpenWriter(w)
/ProgramPattern.
А чем это принципиально отличается от синтаксиса с END'ом? Ровно то же самое терминирующее слово для конкретной конструкции.
-
А чем это принципиально отличается от синтаксиса с END'ом? Ровно то же самое терминирующее слово для конкретной конструкции.
наличием косой черты, полагаю...ну и остальные используемые буквы для каждого случая разные... - вопрос зачем?
-
наличием косой черты, полагаю...ну и остальные используемые буквы для каждого случая разные... - вопрос зачем?
Помогает в случае убогого редактора :) Так же как и КАПС ;)
-
А чем это принципиально отличается от синтаксиса с END'ом? Ровно то же самое терминирующее слово для конкретной конструкции.
наличием косой черты, полагаю...ну и остальные используемые буквы для каждого случая разные... - вопрос зачем?
Ну, косая черта вообще зло - зело не читабельно, да и как бы деление тоже косая черта.
Тогда уж END WHILE писать и там END ЧТО-ТО-ТАМ. Как это в той же Аде бывает. Помогает когда у нас лесенка из вложенных блоков/конструкций.
С другой стороны, такие лесенки нужно давить в зародыше по возможности. Иначе код имеет свойство превращаться в странную какашку с чалмой.
-
Сделайте уже питоноподобный синтаксис и не парьтесь всякими /while и end if
-
Сделайте уже питоноподобный синтаксис и не парьтесь всякими /while и end if
Тогда уж сразу хаскелеподобный :-)
-
module ProgramPattern:
import Texts, Oberon
var w: Texts.Writer
def copy(r: Texts.Reader):
var ch: char
Texts.Read(r, ch)
while ~r.eot:
Texts.Write(w, ch)
Texts.Read(r, ch)
def SomeCommand*:
var r: Texts.Reader
Texts.OpenReader(r, Oberon.This.text, Oberon.Par.pos)
copy(r, w)
Texts.Append(Oberon.Log, w.buf)
Texts.OpenWriter(w)
о! Красота!
-
о! Красота!
Угу. Самый человечный синтаксис. Не устаю повторять :)
-
о! Красота!
Угу. Самый человечный синтаксис. Не устаю повторять :)
А нифига. У хаскелля лучше. По крайней мере там нет этих мусорных def'ов и var'ов.
Это ж надо додуматься вместо "int a" писать "var a:int"
-
Ну, косая черта вообще зло - зело не читабельно, да и как бы деление тоже косая черта.
Тогда уж END WHILE писать и там END ЧТО-ТО-ТАМ. Как это в той же Аде бывает.
Косая черта взята из xml'я. Впринципе, наподобии ады и получается, только вместо END - /
-
о! Красота!
Только убираем var и def.
-
о! Красота!
Только убираем var и def.
Угу. И неплохо бы еще функции показать а не только голимые процедуры (и, боюсь, после этого окажется, что объявления в стиле Си будут более экономичны и лаконичны).
-
Конструкцию с end можно оставить там, где сейчас: end name.
-
Сделайте уже питоноподобный синтаксис и не парьтесь всякими /while и end if
Тогда уж сразу хаскелеподобный :-)
давайте тогда уж Лисп подобный- такое же г. но хоть парится не надо с запоминанием г. на.. только считай себе скобки..
-
Сделайте уже питоноподобный синтаксис и не парьтесь всякими /while и end if
Тогда уж сразу хаскелеподобный :-)
давайте тогда уж Лисп подобный- такое же г. но хоть парится не надо с запоминанием г. на.. только считай себе скобки..
Вопрос - в каком месте СИНТАКСИСА хаскелля нужно что-то запоминать?
-
Мне синтаксис питона, кажется незаконченным. При if then end код более строгий. Глаз цепляется за end. Мне удобнее воспринимать блочно.
После синтаксиса паскаля, синтаксис оберуна прекрасен.
Вопрос намного глубже. Удобнее или полезнее. К примеру сесть в кресло и положить ноги на стол, и клавиатуру на живот, удобнее, но не полезно.
Или всё дело в привычке, в си, с++, паскаль, джава и т.д строгий блок кода.
Что бы я добавил.
1. условие в одну строку
if (c >= "a") and (c <= "z") or (c >= "A") and (c <= "z") then
код
else
Убрать точку с запятой
неправильно
x := (a +b)*c; y := m + d;
правильно
x := (a +b)*c
y := m + d
Всё это лишь моё личное мнение, не подкрепленное десятками проектов, и тысячами строк кода.
Я уверен в том, что синтаксис языка нужно не придумывать, а разрабатывать.
-
С точками с запятой действительно нужно что-то делать, в обероне да и в С их явная избыточность.
-
Взято отсюда http://habrahabr.ru/post/152889/
Определение функций
Вы можете определять функции следующим образом:
На C:
int f(int x, int y) {
return x*x + y*y;
}
На Javascript:
function f(x,y) {
return x*x + y*y;
}
На Python:
def f(x,y):
return x*x + y*y
На Ruby:
def f(x,y)
x*x + y*y
end
На Scheme:
(define (f x y)
(+ (* x x) (* y y)))
И наконец, Haskell:
f x y = x*x + y*y
Очень четко. Ни скобок, ни def-ов.
-
Взято отсюда http://habrahabr.ru/post/152889/
Определение функций
Вы можете определять функции следующим образом:
На C:
int f(int x, int y) {
return x*x + y*y;
}
На Javascript:
function f(x,y) {
return x*x + y*y;
}
На Python:
def f(x,y):
return x*x + y*y
На Ruby:
def f(x,y)
x*x + y*y
end
На Scheme:
(define (f x y)
(+ (* x x) (* y y)))
И наконец, Haskell:
f x y = x*x + y*y
Очень четко. Ни скобок, ни def-ов.
Ну таки да. Особенно если учесть, что однобуквенные названия функций пишут только те, кто сам себе злобный буратино. Вообще, если смотреть конкретно на СИНТАКСИС haskell'a то объявление функции будет такое:
foo :: Integer Integer -> Integer
foo a b = a*a + b*b
Это проще читать и редактировать чем сишный вариант. Другие варианты вообще в пролете - просто потому что там используется динамическая типизация (то есть в синтаксисе нет вообще ничего про типы). (замечу, что и в хаскельном изначальном варианте типиазция также строгая статическая, в отличае от того же питона например).
-
Сделайте уже питоноподобный синтаксис и не парьтесь всякими /while и end if
Тогда уж сразу хаскелеподобный :-)
давайте тогда уж Лисп подобный- такое же г. но хоть парится не надо с запоминанием г. на.. только считай себе скобки..
Вопрос - в каком месте СИНТАКСИСА хаскелля нужно что-то запоминать?
Ответ - в любом, хоть Хаскеля, хоть Оберона.. в Лиспе для бедных (Схеме) - всего пара основных форм да штук 5 специальных (разумеется для минимального ЯВУ), которые записываются единообразно
-
foo :: Integer Integer -> Integer
foo a b = a*a + b*b
Мод Оберон:
foo(a, b: int): int
return a*a + b*b
end foo;
-
foo(a, b: int): int
return a*a + b*b
end foo;
А лямбды как записывать? ;)
-
foo(a, b: int): int
return a*a + b*b
end foo;
А лямбды как записывать? ;)
А в Обероне они внезапно появились? :-)
-
Но вообще, мое мнение: питонообразный причесанный синтаксис без изменения грамматики Оберону пошел бы явно на пользу. То есть это многократно увеличило бы шансы на то, что широкие слои проггеронаселения его хотя бы попробуют (ибо у подавляющего большенства аномально-отрицательная реакция на слово begin и end среди ключевых слов).
-
foo(a, b: int): int
return a*a + b*b
end foo;
А лямбды как записывать? ;)
А в Обероне они внезапно появились? :-)
Я к тому, что если уж модифицировать синтаксис,
то нужно предусмотреть возможность безболезненного введения всяких популярных свистоперделок типа лямбд. ;)
В этом плане предложенный вариант не катит, т.к. он "деревянный" :)
-
Но вообще, мое мнение: питонообразный причесанный синтаксис без изменения грамматики Оберону пошел бы явно на пользу. То есть это многократно увеличило бы шансы на то, что широкие слои проггеронаселения его хотя бы попробуют (ибо у подавляющего большенства аномально-отрицательная реакция на слово begin и end среди ключевых слов).
А я одинаково ненавижу как begend'ы так и сишные {}. Но при этом питоновый синтаксис мне кажется перебором. Идеально было бы нечто среднее между Python и Lua. Отсутствие end'ов в питоне мозг отказывается воспринимать. Хрен знает мож это фобии мои...
-
Идеально было бы нечто среднее между Python и Lua.
Это как?
-
Но вообще, мое мнение: питонообразный причесанный синтаксис без изменения грамматики Оберону пошел бы явно на пользу. То есть это многократно увеличило бы шансы на то, что широкие слои проггеронаселения его хотя бы попробуют (ибо у подавляющего большенства аномально-отрицательная реакция на слово begin и end среди ключевых слов).
А я одинаково ненавижу как begend'ы так и сишные {}. Но при этом питоновый синтаксис мне кажется перебором. Идеально было бы нечто среднее между Python и Lua. Отсутствие end'ов в питоне мозг отказывается воспринимать. Хрен знает мож это фобии мои...
А я нормально воспринимаю. Но в принципе, да. В синтаксисе должна быть возможность оформлят не отступами а "скобочками". Иногда это полезно.
В общем, тут хаскелл рулит :-)
-
Идеально было бы нечто среднее между Python и Lua.
Это как?
Функции примерно так наверно:
foo = def(a, b: int): int
return a*a + b*b
end
Т.е. нету луашного длинного function (вместо def можно func)
Но при этом есть end и форма записи лямбдовая...
А такая форма:
def foo(a, b: int): int
return a*a + b*b
end
нинужна вообще :P
Плюс к этому автовывод типов, т.е. тип функции не указывать:
foo = def(a, b: int)
return a*a + b*b
end
и стало совсем ня :D
-
Идеально было бы нечто среднее между Python и Lua.
Это как?
Функции примерно так наверно:
foo = def(a, b: int): int
return a*a + b*b
end
Т.е. нету луашного длинного function (вместо def можно func)
Но при этом есть end и форма записи лямбдовая...
А такая форма:
def foo(a, b: int): int
return a*a + b*b
end
нинужна вообще :P
Плюс к этому автовывод типов, т.е. тип функции не указывать:
foo = def(a, b: int)
return a*a + b*b
end
и стало совсем ня :D
Это меняет не только синтаксис, но и грамматику с семантикой языка.
-
Я б сказал вообще язык меняет ;D
-
Я б сказал вообще язык меняет ;D
Следовательно не подходит. (я не буду говорить хороши эти изменения или плохи, они просто не подходят для рассматриваемой задачи)
-
foo(a, b: int)
return a*a + b*b
end
Чем плоха такая форма?
-
foo(a, b: int)
return a*a + b*b
end
Чем плоха такая форма?
Тем, что без вывода типа это работать не будет. Где указан тип возвращаемого значения?
-
foo(a, b: int)
return a*a + b*b
end
Чем плоха такая форма?
Тем, что без вывода типа это работать не будет. Где указан тип возвращаемого значения?
;D так надо его ввести... а заодно и инициализацию 0 по умолчанию, инициализацию переменных в секции var, для хардкорщиков модификатор undef (показатель что переменная не инициализируется), перегрузку процедур, и вместо безликих end ов - e_rec, e_if,e_for, e_while... и массивы индексируемые с единицы
-
... а для любителе 0 - индексации - модификатор zerobased ;), кроме того дать процедуре возможность возвращать нормально любой тип данных допустимый языком.. а не только простые типы и указатели...
-
foo(a, b: int)
return a*a + b*b
end
Чем плоха такая форма?
Тем, что без вывода типа это работать не будет. Где указан тип возвращаемого значения?
Как анонимная функция не годится?
-
foo(a, b: int)
return a*a + b*b
end
Чем плоха такая форма?
Тем, что без вывода типа это работать не будет. Где указан тип возвращаемого значения?
Как анонимная функция не годится?
Какая ж она анонимная, если у нее есть имя - foo ? :-)
-
foo(a, b: int)
return a*a + b*b
end
Чем плоха такая форма?
Тем, что без вывода типа это работать не будет. Где указан тип возвращаемого значения?
Как анонимная функция не годится?
Какая ж она анонимная, если у нее есть имя - foo ? :-)
тык "foo" и есть показатель анонимности (что бы никто не догадался) ;D
-
инициализацию 0 по умолчанию, инициализацию переменных в секции var, для хардкорщиков модификатор undef (показатель что переменная не инициализируется), перегрузку процедур, и вместо безликих end ов - e_rec, e_if,e_for, e_while... и массивы индексируемые с единицы
0 и nil, секция var не нужна
e_rec, e_if,e_for, e_while - еще варианты: end rec, endrec
про пагубность массивов с единицы уже обсуждалось
-
Какая ж она анонимная, если у нее есть имя - foo ? :-)
сорри
(a, b: int) return a*a + b*b end
-
инициализацию 0 по умолчанию, инициализацию переменных в секции var, для хардкорщиков модификатор undef (показатель что переменная не инициализируется), перегрузку процедур, и вместо безликих end ов - e_rec, e_if,e_for, e_while... и массивы индексируемые с единицы
0 и nil, секция var не нужна
e_rec, e_if,e_for, e_while - еще варианты: end rec, endrec
про пагубность массивов с единицы уже обсуждалось
Нужна...
1. разумеется ( кроме nil, еще и '' - для литер) - все должно иметь начальное значение..
2. нужна.. - в противном случае мыбудем иметь блочную локальность - а это уже не Оберон
3. Херня -это обсуждение обдолбаных технофошистов- рептилоидов! впрочем , если им неймется... пусть пишут zerobased - перед array
- секция var - нц
-
Какая ж она анонимная, если у нее есть имя - foo ? :-)
сорри
(a, b: int) return a*a + b*b end
Это полумеры (в обе стороны).
Чтобы было понятно куда двигаться, скажи, где предполагается использовать анонимные функции? (не делаем же мы их, просто для того чтобы "было")
-
да... что тогда будем .. иметь:
1 секционную организацию модуля сохраним
2. END - нафиг (е_module и e_proc без повторения названий )
3 предопределенную инициализацию
4 примитивную модель памяти
5 перегрузку функций
6 равноправность переменных в интерфейсе процедур
вроде сильно не обгадив основную идею Вирта
еще бы repeat until бы говенный заменить...
-
и, разумеется дефолтным сделать utf-8 ... с возможностью ввода русскоязычных идентификаторов
-
разумеется ( кроме nil, еще и '' - для литер) - все должно иметь начальное значение..
2. нужна.. - в противном случае мыбудем иметь блочную локальность - а это уже не Оберон
если нужна, то только без слова var, а саму секцию можно завершить ;
кстати, мы так лихо порезали ; где его еще можно притулить?
-
2. END - нафиг (е_module и e_proc без повторения названий )
может eif, erec, emodule, efor?
proc, e_proc - не нужен, просто foo()
уже определяет, что это процедура или функция.
вроде сильно не обгадив основную идею Вирта
еще бы repeat until бы говенный заменить...
Так уже обговорили, что лучше do while и while do
-
разумеется ( кроме nil, еще и '' - для литер) - все должно иметь начальное значение..
2. нужна.. - в противном случае мыбудем иметь блочную локальность - а это уже не Оберон
если нужна, то только без слова var, а саму секцию можно завершить ;
кстати, мы так лихо порезали ; где его еще можно притулить?
1. нужна
2. избыточно
3. для чего ?
-
Так уже обговорили, что лучше do while и while do
а что такое erec - сокращение от erection? - нет ... принцип построения
у форм должен быть один начинаться с id (уникальный идентификатор формы) - кончаться e_id (добавлением e_ к идентификатору)
-
Чтобы было понятно куда двигаться, скажи, где предполагается использовать анонимные функции? (не делаем же мы их, просто для того чтобы "было")
Сложно сказать, где они незаменимы, может как сахар.
-
ну и оператор := заменить на <-
-
а что такое erec - сокращение от erection? - нет ... принцип построения
у форм должен быть один начинаться с id (уникальный идентификатор формы) - кончаться e_id (добавлением e_ к идентификатору)
erecord
начинаться с id, заканчиваться с eid
-
фигня , вот решение задачи Петра на это языке..
MOD ttt;
VAR
M1:ARRAY [8] OF INTEGER <- ( 1, 2, 3, 4, 5, 6, 7, 0 );
M2:ARRAY [9] OF INTEGER <- ( 28, 1, 2, 3, 4, 5, 6, 7, 0 );
M3:ARRAY [11] OF INTEGER <- ( 38, 39, 30, 1, 2, 3, 4, 5, 6, 7, 0 );
M4:ARRAY [12] OF INTEGER <- ( 1, 2, 3, 4, 5, 6, 7, 48, 0 );
M5:ARRAY [11] OF INTEGER <- ( 1, 2, 3, 4, 5, 6, 7, 58, 59, 50, 0 );
M6:ARRAY [9] OF INTEGER <- ( 1, 2, 3, 68, 4, 5, 6, 7, 0 );
M7:ARRAY [11] OF INTEGER <- ( 1, 2, 3, 78, 79, 70, 4, 5, 6, 7, 0 );
M8:ARRAY [16] OF INTEGER <- ( 1, 2, 80, 81, 82, 3, 4, 5, 83, 84, 6, 7, 85, 86, 87,0 );
PROC PrintDiff(a,b:ARRAY OF INTEGER);
VAR i,j:INTEGER;
BEGIN
i<-1; j<-1;
WHILE a[i] ~= 0 DO //общая внутренность
WHILE a[i] ~= b[j] DO
WRITE (b[j], ' ');
INC(j);
E_WHILE;
WRITELN;
INC(i);
INC(j);
E_WHILE;
WHILE b[j] <> 0 DO // пропущенный мною хвост
WRITE (b[j], ' ');
INC(j);
E_END;
E_PROC;
BEGIN
PrintDiff(M1,M8);
Readln;
E_MOD.
кстати... надо будет вводить кортежи.. если хотим нормальную инициализацию всего..
-
обратите внимание на i<-1 ;)
-
так что...
MOD ttt;
VAR
M1:ARRAY [8] OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 0 );
M2:ARRAY [9] OF INTEGER := ( 28, 1, 2, 3, 4, 5, 6, 7, 0 );
M3:ARRAY [11] OF INTEGER := ( 38, 39, 30, 1, 2, 3, 4, 5, 6, 7, 0 );
M4:ARRAY [12] OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 );
M5:ARRAY [11] OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 58, 59, 50, 0 );
M6:ARRAY [9] OF INTEGER := ( 1, 2, 3, 68, 4, 5, 6, 7, 0 );
M7:ARRAY [11] OF INTEGER := ( 1, 2, 3, 78, 79, 70, 4, 5, 6, 7, 0 );
M8:ARRAY [16] OF INTEGER := ( 1, 2, 80, 81, 82, 3, 4, 5, 83, 84, 6, 7, 85, 86, 87,0 );
PROC PrintDiff(a,b:ARRAY OF INTEGER);
VAR i,j:INTEGER;
BEGIN
i:=1; j:=1;
WHILE a[i] ~= 0 DO //общая внутренность
WHILE a[i] ~= b[j] DO
WRITE (b[j], ' ');
INC(j);
E_WHILE;
WRITELN;
INC(i);
INC(j);
E_WHILE;
WHILE b[j] ~= 0 DO // пропущенный мною хвост
WRITE (b[j], ' ');
INC(j);
E_WHILE;
E_PROC;
BEGIN
PrintDiff(M1,M8);
READLN;
E_MOD
;)
;D ;D ;D ;D ;D
-
Так уже обговорили, что лучше do while и while do
вы хотите получить в пределе связку
WHILE .. DO
DO
...
WHILE ..;
E_WHILE
;)
хотя это лучше чем
WHILE .. DO
DO
...
WHILE ..;
END;
;)
-
M4:ARRAY [12] OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 );
По моему, тут проблемы. Нужно следить чтобы число объявленных слева соответствовало тому, что справа. И это дико не удобно.
И, кстати, тут не соответствует.
-
M4:ARRAY [12] OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 );
По моему, тут проблемы. Нужно следить чтобы число объявленных слева соответствовало тому, что справа. И это дико не удобно.
И, кстати, тут не соответствует.
1. нет .... это для статики... а это - M4:ARRAY OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 ); - для динамики
2. да блин... надо честно писать на языке... а не заниматься.. правками на скорую руку...
-
M4:ARRAY [12] OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 );
По моему, тут проблемы. Нужно следить чтобы число объявленных слева соответствовало тому, что справа. И это дико не удобно.
И, кстати, тут не соответствует.
1. нет .... это для статики... а это - M4:ARRAY OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 ); - для динамики
Я не вижу тут динамики, хоть убей. Это банальная статика - все же известно на этапе компиляции.
-
Но вообще, мое мнение: питонообразный причесанный синтаксис без изменения грамматики Оберону пошел бы явно на пользу. То есть это многократно увеличило бы шансы на то, что широкие слои проггеронаселения его хотя бы попробуют (ибо у подавляющего большенства аномально-отрицательная реакция на слово begin и end среди ключевых слов).
Ага. А от КАПСа веет прошлым веком (серьезно).
-
Правильно будет:
M4: [9] int := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 )
M4: [] int := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 )
-
Но вообще, мое мнение: питонообразный причесанный синтаксис без изменения грамматики Оберону пошел бы явно на пользу. То есть это многократно увеличило бы шансы на то, что широкие слои проггеронаселения его хотя бы попробуют (ибо у подавляющего большенства аномально-отрицательная реакция на слово begin и end среди ключевых слов).
Ага. А от КАПСа веет прошлым веком (серьезно).
а ту технофошиста - мы за дерьмократию !
-
Правильно будет:
M4: [9] int := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 )
M4: [] int := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 )
статика, динамика
не правильно.. разрыв стиля - новая форма без необходимости
-
Это обероновский стиль. От чудовищных конструкций типа ARRAY OF необходимо избавиться, как и от бегинов.
-
против кортежей , кстати, никто не против?
TYPE
MREC=RECORD
A:ARRAY[4] OF INTEGER;
S:CHAR;
R:REAL;
AA:ARRAY OF ARRAY OF CHAR;
E_RECORD
VAR
R:MREC:={
( 1,2,3,4),
'b',
3,1415,
(('a','b')('c','d','e'))
}
-
Это обероновский стиль. От чудовищных конструкций типа ARRAY OF необходимо избавиться, как и от бегинов.
Стиль Обероновский- ничего не делать без необходимости... в противном случае давайте засерать СИ... (Питоны и С++ уже засраны)
-
кстати .. введение кортежей привносит проблему глубокого копирования... а также возможен гемор.. с записью - классом..
-
как, например, инициализировать кортеж содержащий процедуру - оператора взятия адреса нет.. вводить новый?
-
M4:ARRAY [12] OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 );
По моему, тут проблемы. Нужно следить чтобы число объявленных слева соответствовало тому, что справа. И это дико не удобно.
И, кстати, тут не соответствует.
1. нет .... это для статики... а это - M4:ARRAY OF INTEGER := ( 1, 2, 3, 4, 5, 6, 7, 48, 0 ); - для динамики
Я не вижу тут динамики, хоть убей. Это банальная статика - все же известно на этапе компиляции.
здесь нет, но размер второго вариант мы можем изменять во время исполнения
..
setlength(M4, 20);
..
-
как, например, инициализировать кортеж содержащий процедуру - оператора взятия адреса нет.. вводить новый?
Ничего не понял. Кортеж это ж просто не именованная структура (ака запись) с, вероятно, позиционными полями (но могут быть и именованные). При этом все остается на месте, в том числе и строгая статическая типизация.
Где тут проблемы? И где тут отличие, в плане глубокого копирования, от обычных именованных записей/структур?
-
как, например, инициализировать кортеж содержащий процедуру - оператора взятия адреса нет.. вводить новый?
Ничего не понял. Кортеж это ж просто не именованная структура (ака запись) с, вероятно, позиционными полями (но могут быть и именованные). При этом все остается на месте, в том числе и строгая статическая типизация.
Где тут проблемы? И где тут отличие, в плане глубокого копирования, от обычных именованных записей/структур?
а представьте себе.. что она содержит указатель ... который может быть как nil, так и содержать адрес первого узла некоторого графа...
где нам остановиться при выполнении операции присваивания?
-
как, например, инициализировать кортеж содержащий процедуру - оператора взятия адреса нет.. вводить новый?
Ничего не понял. Кортеж это ж просто не именованная структура (ака запись) с, вероятно, позиционными полями (но могут быть и именованные). При этом все остается на месте, в том числе и строгая статическая типизация.
Где тут проблемы? И где тут отличие, в плане глубокого копирования, от обычных именованных записей/структур?
а представьте себе.. что она содержит указатель ... который может быть как nil, так и содержать адрес первого узла некоторого графа...
где нам остановиться при выполнении операции присваивания?
Ровно там же, где и при выполнении операции присваивания обычной записи в этой же ситуации.
-
далее , пусть мы совершаем глубокое копирование...
но тогда .. рассмотрим процедуру возвращающую такой кортеж.... получается, что она в принципе может при одном определении возвращаемого типа возвращать объекты произвольной структуры...
-
как, например, инициализировать кортеж содержащий процедуру - оператора взятия адреса нет.. вводить новый?
Ничего не понял. Кортеж это ж просто не именованная структура (ака запись) с, вероятно, позиционными полями (но могут быть и именованные). При этом все остается на месте, в том числе и строгая статическая типизация.
Где тут проблемы? И где тут отличие, в плане глубокого копирования, от обычных именованных записей/структур?
а представьте себе.. что она содержит указатель ... который может быть как nil, так и содержать адрес первого узла некоторого графа...
где нам остановиться при выполнении операции присваивания?
Ровно там же, где и при выполнении операции присваивания обычной записи в этой же ситуации.
тогда это не кортеж...- имеем неполную операцию присваивания...
-
блин, тогда нужно вводить оператор глубокого копирования.. как в Эйфеле..вот так.. языки постепенно обрастают говнецом....
-
а с другой стороны .. нафига нам полноценный кортеж? = достаточно расширение (полезное) понятия инициализации записи...
-
далее , пусть мы совершаем глубокое копирование...
но тогда .. рассмотрим процедуру возвращающую такой кортеж.... получается, что она в принципе может при одном определении возвращаемого типа возвращать объекты произвольной структуры...
Опять ничего не понял (что-то я нонче тупой похоже). Каким образом? У кортежа - вполне конкретный тип, сигнатура. Всегда.
Соответственно будет нечто вроде
PROCEDIRE Foo() : (INTEGER, REAL)
И еще - пожалуйста определи что в твоем понимании "полноценный кортеж". Ибо я нигде не видел чтобы по умолчанию в кортеже было глубокое копирование.
-
И еще - пожалуйста определи что в твоем понимании "полноценный кортеж". Ибо я нигде не видел чтобы по умолчанию в кортеже было глубокое копирование.
по умолчанию его может и не быть , но для полноты концепции нужно вводить соответствующий оператор вообщем.. лучше не использовать слово КОРТЕЖ ( TUPLE) - использовать расширение понятие запись... или его вводить как новый тип (наравне с записью)
-
Опять ничего не понял (что-то я нонче тупой похоже). Каким образом? У кортежа - вполне конкретный тип, сигнатура. Всегда.
Соответственно будет нечто вроде
PROCEDIRE Foo() : (INTEGER, REAL)
И еще - пожалуйста определи что в твоем понимании "полноценный кортеж". Ибо я нигде не видел чтобы по умолчанию в кортеже было глубокое копирование.
для таких кортежей проблем нет... а вы попробуйте инициализировать кортеж содержащий значение функционального типа... или указателя
Какая разница?
PROCEDIRE Foo() : (INTEGER, POINTER TO MyRecord)
VAR p : POINTER TO MyRecord;
BEGIN
NEW(p);
RETURN (42, p);
END
-
PROCEDIRE Foo() : (INTEGER, REAL)
с этой фигней нормально.. а если параметром кортежа будет значение переменной процедурного типа?
-
PROCEDIRE Foo() : (INTEGER, REAL)
с этой фигней нормально.. а если параметром кортежа будет значение переменной процедурного типа?
Так я же пример с указателем привел следующим ответом.
-
PROCEDIRE Foo() : (INTEGER, REAL)
с этой фигней нормально.. а если параметром кортежа будет значение переменной процедурного типа?
Так я же пример с указателем привел следующим ответом.
я имею ввиду инициализацию в секции VAR ... ,
-
3. Херня -это обсуждение обдолбаных технофошистов- рептилоидов! впрочем , если им неймется... пусть пишут zerobased - перед array
- секция var - нц
zerobased - херня :) Усугубление проблемы. Потому что нормального человека все равно потом будет плющить от кода Дизера, даже если они и расставит там явно onebased ;) Нужна как минимум добавочная типизация для индеков - чтобы zerobased индекс нельзя было использовать для индексации onebased массива и наоборот. А это еще одно усложнение. И все равно будет хреново.
Мы на плюсах такое делали. Было какое-то немаленькое количество кода (что-то типа древнючей паскальной либы переписанной на С++) с тотальной единичной индексацией (паскаль, ага). Но могу врать, может и еще чего-то. Не важно. В какой-то момент нас окончательно задолбало фиксить баги, возникающие из-за разной индексации. Сделали типизированные индексы, даже стандартный вектор (std::vector) заспециализировали, чтобы оно гладко работало с такими индексами. Баги как бы исчезли, но вот головная боль от преобразований туда-сюда - осталась.
Вывод: подобная "дуальность" в языке - однозначное зло. А почему в языке (общего назначения) должен быть именно zerobased - уже обсуждалось.
-
я имею ввиду инициализацию в секции VAR ... ,
Так, кажется я начинаю понимать что тебя интересует. Интересует тебя, видимо, не секция VAR, а как модифицировать одно из полей уже существующей переменной-кортежа. Это так?
-
я имею ввиду инициализацию в секции VAR ... ,
Так, кажется я начинаю понимать что тебя интересует. Интересует тебя, видимо, не секция VAR, а как модифицировать одно из полей уже существующей переменной-кортежа. Это так?
это тоже интересует (если мы собираемся давать возможность определять переменную такого типа... если ограничимся только значением (совместимым по присваиванию с переменной типа запись в определенных случаях)- то нет), но мне не нравится, то что в общем случае , невозможно определять полноценно значения переменных в секции VAR...
-
я имею ввиду инициализацию в секции VAR ... ,
Так, кажется я начинаю понимать что тебя интересует. Интересует тебя, видимо, не секция VAR, а как модифицировать одно из полей уже существующей переменной-кортежа. Это так?
это тоже интересует (если мы собираемся давать возможность определять переменную такого типа... если ограничимся только значением (совместимым по присваиванию с переменной типа запись в определенных случаях)- то нет), но мне не нравится, то что в общем случае , невозможно определять полноценно значения переменных в секции VAR...
В секции VAR и так никого инициализировать нельзя в Обероне :-)
А модифицировать очень просто:
VAR
a : (INTEGER, POINTER TO MyRecord)
b : POINTER TO MyRecord
BEGIN
a[0] := 42;
NEW(b);
a[1] := b;
NEW(a[1]);
RETURN a;
END
-
тык это в Обероне.. я же говорю про засераемый нами Обсерон... ;D ... тогда
инициализация в секции VAR не очень хорошая идея.. как и <- ;)
-
тык это в Обероне.. я же говорю про засераемый нами Обсерон... ;D ... тогда
инициализация в секции VAR не очень хорошая идея.. как и <- ;)
VAR
a : (INTEGER, POINTER TO MyRecord)
b : POINTER TO MyRecord
BEGIN
a := (42, b);
END
Не вижу проблем втащить то же самое в секцию VAR.
В секции VAR при инициализации указателей, безотносительно туплов, будет одна проблемка - если хочется чтобы указатель сразу указывал на новую сущность в куче, то ничего не выйдет, ведь NEW не функция а процедура. То есть a = new Foo; не получится сделать.
-
хорошо повеселились, однако :)
-
Не вижу проблем втащить то же самое в секцию VAR.
В секции VAR при инициализации указателей, безотносительно туплов, будет одна проблемка - если хочется чтобы указатель сразу указывал на новую сущность в куче, то ничего не выйдет, ведь NEW не функция а процедура. То есть a = new Foo; не получится сделать.
я вижу.. если уж ручками инициализируем переменную, то она должна быть заполнена нормальными значениями (иметь непротиворечивое состояние относительно логики программы ), а если поле типа указатель или функциональный тип будет ВСЕГДА NIL (если инициализировать ее в секции VAR) - то это не комильфо
-
Не вижу проблем втащить то же самое в секцию VAR.
В секции VAR при инициализации указателей, безотносительно туплов, будет одна проблемка - если хочется чтобы указатель сразу указывал на новую сущность в куче, то ничего не выйдет, ведь NEW не функция а процедура. То есть a = new Foo; не получится сделать.
я вижу.. если уж ручками инициализируем переменную, то она должна быть заполнена нормальными значениями (иметь непротиворечивое состояние относительно логики программы ), а если поле типа указатель или функциональный тип будет ВСЕГДА NIL (если инициализировать ее в секции VAR) - то это не комильфо
Не всегда.
TYPE T = POINTER TO MyRecord;
PROCEDURE Foo(p : T)
VAR
a : T := p
b : (INTEGER, T) := (42, p)
BEGIN
END
-
Не вижу проблем втащить то же самое в секцию VAR.
В секции VAR при инициализации указателей, безотносительно туплов, будет одна проблемка - если хочется чтобы указатель сразу указывал на новую сущность в куче, то ничего не выйдет, ведь NEW не функция а процедура. То есть a = new Foo; не получится сделать.
я вижу.. если уж ручками инициализируем переменную, то она должна быть заполнена нормальными значениями (иметь непротиворечивое состояние относительно логики программы ), а если поле типа указатель или функциональный тип будет ВСЕГДА NIL (если инициализировать ее в секции VAR) - то это не комильфо
Не всегда.
TYPE T = POINTER TO MyRecord;
PROCEDURE Foo(p : T)
VAR
a : T := p
b : (INTEGER, T) := (42, p)
BEGIN
END
это еще хуже..
-
По моим ощущениям, после беглой оценки, введение кортежей в Оберон-07/11 весьма не трудоемко и не должно что-либо порушить. То есть вписаться они должны в язык достаточно гладко.
Но это на первый взгляд. Возможно я что-то упускаю.
Вопрос к vlad'у - как ты считаешь, насколько это трудоемко интегрировать в оный Оберон?
PS. Я не предлагаю интегрировать прямо сейчас.
-
foo(a, b: int): int
return a*a + b*b
end foo;
А лямбды как записывать? ;)
типа того:
lamdba(a, b: int): int
return a*a + b*b
end
-
... а для любителе 0 - индексации - модификатор zerobased ;), кроме того дать процедуре возможность возвращать нормально любой тип данных допустимый языком.. а не только простые типы и указатели...
Нафига? Надо просто вернуть старый паскалевский стиль объявления массивов:
xs: array [1..10] of integer;
ys: array [0..9] of byte;
-
с возможностью ввода русскоязычных идентификаторов
А вот это -- запретить под страхом смертной казни!!!
-
foo(a, b: int): int
return a*a + b*b
end foo;
А лямбды как записывать? ;)
типа того:
lamdba(a, b: int): int
return a*a + b*b
end
отличие в использовании слова lamdba ? - логично, но не прикольно...
-
с возможностью ввода русскоязычных идентификаторов
А вот это -- запретить под страхом смертной казни!!!
;D ого рускоязычный русофоб.. ну ну....
-
с возможностью ввода русскоязычных идентификаторов
А вот это -- запретить под страхом смертной казни!!!
;D ого рускоязычный русофоб.. ну ну....
Рускоязычные идентификаторы (и ключевые слова) лично мною также очень плохо воспринимаются.
-
... а для любителе 0 - индексации - модификатор zerobased ;), кроме того дать процедуре возможность возвращать нормально любой тип данных допустимый языком.. а не только простые типы и указатели...
Нафига? Надо просто вернуть старый паскалевский стиль объявления массивов:
xs: array [1..10] of integer;
ys: array [0..9] of byte;
да, это для статики, а для динамики?
-
... а для любителе 0 - индексации - модификатор zerobased ;), кроме того дать процедуре возможность возвращать нормально любой тип данных допустимый языком.. а не только простые типы и указатели...
Нафига? Надо просто вернуть старый паскалевский стиль объявления массивов:
xs: array [1..10] of integer;
ys: array [0..9] of byte;
да, это для статики, а для динамики?
А что такое динамика? ;-)
-
с возможностью ввода русскоязычных идентификаторов
А вот это -- запретить под страхом смертной казни!!!
;D ого рускоязычный русофоб.. ну ну....
Рускоязычные идентификаторы (и ключевые слова) лично мною также очень плохо воспринимаются.
это потому, что уже испорчены... насчет слов.. пожалуй соглашусь- они воспринимаются как формы или их часть.. а вот идентификаторы.... с ними у начинающих небольшая проблема.. и потом, вон 1с -нику Борису.. они не мешают.
-
... а для любителе 0 - индексации - модификатор zerobased ;), кроме того дать процедуре возможность возвращать нормально любой тип данных допустимый языком.. а не только простые типы и указатели...
Нафига? Надо просто вернуть старый паскалевский стиль объявления массивов:
xs: array [1..10] of integer;
ys: array [0..9] of byte;
да, это для статики, а для динамики?
А что такое динамика? ;-)
массив размер которого может меняться во время исполнения программы.. или таких у нас нет?
-
... а для любителе 0 - индексации - модификатор zerobased ;), кроме того дать процедуре возможность возвращать нормально любой тип данных допустимый языком.. а не только простые типы и указатели...
Нафига? Надо просто вернуть старый паскалевский стиль объявления массивов:
xs: array [1..10] of integer;
ys: array [0..9] of byte;
да, это для статики, а для динамики?
для динамики обявлять переменную так:
zs: array of real;
а при изменении размера так:
zs := new array[1..100];
или
zs := new array[0..15];
Типа того...
-
массив размер которого может меняться во время исполнения программы.. или таких у нас нет?
Таких нет. Более того, в Обероне-07 вообще нет массивов с размером неизвестным на этапе компиляции.
-
операторная форма NEW? , по Оберонски это будет NEW(A, ARRAY[1.100]) - не кошерно как то...
-
массив размер которого может меняться во время исполнения программы.. или таких у нас нет?
Таких нет. Более того, в Обероне-07 вообще нет массивов с размером неизвестным на этапе компиляции.
блин.. да энто же в КП... а мы меняем Оберон07?
-
массив размер которого может меняться во время исполнения программы.. или таких у нас нет?
Таких нет. Более того, в Обероне-07 вообще нет массивов с размером неизвестным на этапе компиляции.
блин.. да энто же в КП... а мы меняем Оберон07?
Это именно в Oberon-07, а не в КП.
-
операторная форма NEW? , по Оберонски это будет NEW(A, ARRAY[1.100]) - не кошерно как то...
хотя нет... имхо лучше чем NEW(A, 100) из КП - нет ложного ощущения, что NEW -процедура...
-
массив размер которого может меняться во время исполнения программы.. или таких у нас нет?
Таких нет. Более того, в Обероне-07 вообще нет массивов с размером неизвестным на этапе компиляции.
блин.. да энто же в КП... а мы меняем Оберон07?
Это именно в Oberon-07, а не в КП.
вроде в КП это можно, разве нет?
-
вроде в КП это можно, разве нет?
В КП есть массивы неизвестной на этапе компиляции длинны.
-
а вообще, господа, - когда угар веселья прошел.. может кто то ответит мне.. что мы хотим добиться (кроме развлекалова ) ?
-
вроде в КП это можно, разве нет?
В КП есть массивы неизвестной на этапе компиляции длинны.
согласен.. некорректно называть то что есть КП- "массивами с динамически изменяемым размером"
-
но если 07 менять.. то кортежи там выглядят как мотор от БМВ в запорожце... нафига это надо?
-
xs: array [1..10] of integer;
ys: array [0..9] of byte;
xs:[1..10] int
ys:[0..9] byte или тоже самое ys:[9] byte, так как с нуля
намного красивее.
-
но если 07 менять.. то кортежи там выглядят как мотор от БМВ в запорожце... нафига это надо?
Вполне ниче так...
(http://tebus.users.photofile.ru/photo/tebus/92342/xlarge/1457345.jpg)
-
Вопрос к vlad'у - как ты считаешь, насколько это трудоемко интегрировать в оный Оберон?
Да фиг его знает. Пока не пощупаешь не понятно. Может как с NEW оказаться - весь опыт показывает, что в обероне он неправильный, но потом оказывается, что правильный new в оберон не вписывается.
-
но если 07 менять.. то кортежи там выглядят как мотор от БМВ в запорожце... нафига это надо?
наверное, чтобы летал... на кочках
-
Насчет end'ов.
Было рассмотрено много примеров мод оберона без использования точки с запятой. Можно сделать так: end оставить в именованых конструкциях, таких как модули, процедуры: end name;
а в остальных случаях использовать вместо end, точку с запятой: if...then...else...; while...do...;
-
";" также подходит вместо бегина как завершитель секции VAR в процедурах.
Кстати, Вирт уже использовал подобную конструкцию с ";" вместо end:repeat...until...;
-
Насчет end'ов.
Было рассмотрено много примеров мод оберона без использования точки с запятой. Можно сделать так: end оставить в именованых конструкциях, таких как модули, процедуры: end name;
а в остальных случаях использовать вместо end, точку с запятой: if...then...else...; while...do...;
Vartovyj - зачем вам это нужно? вроде как уже и не смешно.. но если вы всерьез, то озаботьтесь 1. достойной целью, 2. попробуйте понять философию Oберона, и каждое свое "предложение" соразмеряйте с этим пунктами.. и учтите,что даже в этом случае возможны проблемы .. я специально показал вам на примере
казалось безобидной и "правильной" замены := на <- возможно разночтение (разумеется на уровне человеческого восприятия, компилятор эту проблему выловит), казалось, наглядная идея кастомной инициализации переменных в секции VAR, соответствующая философии языка, - ведет к появлению исключений.. наконец, банальное внедрение нового типа (кортежей) плохо вписывается в язык.. (не говоря уж о неименованных подпрограммах, жестко нарушающих концепцию языка - вы пытаетесь ввести их не представляя даже зачем это нужно в нем).
-
мракобесы )))
лучше бы пользу нанесли
-
мракобесы )))
лучше бы пользу нанесли
:D Так в чем она должна заключаться, кому пойдет эта польза , о Kemet, просветите дураков ... а то , а вот сказал слово "польза" .. и ничего не изменилось... может ударение не на ту букву поставил.. с чем черт не шутит...
-
:D Так в чем она должна заключаться, кому пойдет эта польза , о Kemet, просветите дураков ... а то , а вот сказал слово "польза" .. и ничего не изменилось... может ударение не на ту букву поставил.. с чем черт не шутит...
Да хоть самому себе, а то такая бредятина, что просто жуть... полнолуние что-ли?
Я понимаю, что отдельные личности, как всегда, стебаются, но некоторых жеж всерьез плющит...
Ав вдруг неокрепший разум прочтёт, это ж никакой доктор потом не поможет )
-
:D Так в чем она должна заключаться, кому пойдет эта польза , о Kemet, просветите дураков ... а то , а вот сказал слово "польза" .. и ничего не изменилось... может ударение не на ту букву поставил.. с чем черт не шутит...
Да хоть самому себе, а то такая бредятина, что просто жуть... полнолуние что-ли?
Я понимаю, что отдельные личности, как всегда, стебаются, но некоторых жеж всерьез плющит...
Ав вдруг неокрепший разум прочтёт, это ж никакой доктор потом не поможет )
тык я свое то получил (свою пользу - в виде развлечения на вечер).. :D... вы не мне ответьте ;)
-
казалось безобидной и "правильной" замены := на <- возможно разночтение (разумеется на уровне человеческого восприятия, компилятор эту проблему выловит)
я против этой замены по чисто эстетическим причинам
идея кастомной инициализации переменных в секции VAR, соответствующая философии языка, - ведет к появлению исключений
отсутствие этой секции, как в Си ведет к исключениям?
Насчет end и ; это как раз причесывание в стиле питона и луа, оставляя особенности оберона.
-
Вот видите Kemet
казалось безобидной и "правильной" замены := на <- возможно разночтение (разумеется на уровне человеческого восприятия, компилятор эту проблему выловит)
я против этой замены по чисто эстетическим причинам
идея кастомной инициализации переменных в секции VAR, соответствующая философии языка, - ведет к появлению исключений
отсутствие этой секции, как в Си ведет к исключениям?
Насчет end и ; это как раз причесывание в стиле питона и луа, оставляя особенности оберона.
1. а меня проблемы при интерпретации человеком a <- 1 и а < -1
2.В Обероне переменные определяемые в секции VAR можно считать создаваемыми либо перед выполнением программы, либо в момент вызова процедуры.. и это для ряда задач БЛАГО, в СИ это не так...
Мне не понравился следующий момент - если возможность занесения в переменную значения ДО выполнения первой исполняемой инструкции программы, то должна она реализоваться ПОЛНОСТЬЮ (если это допустимо задачей).. а тут мы имеем, в ряде случаев, ограничения.. причем, как показал Алексей, их количество зависит от того, глобальные переменные или локальные...
-
1. а меня проблемы при интерпретации человеком a <- 1 и а < -1
Правильно. Поэтому нужно писать так:
a ← 1
Собственно в том же Haskell'e так и пишется. Но при этом в редакторе НАБИРАЕТСЯ <-, что автозаменяется вумным редактором на ←
-
2.В Обероне переменные определяемые в секции VAR можно считать создаваемыми либо перед выполнением программы, либо в момент вызова процедуры.. и это для ряда задач БЛАГО, в СИ это не так...
В Си и С++ это как раз так.
Точнее, тут нужно уточнить что значит "создаются". Память под них выделяется на стеке в момент вызова функции. А использовать их можно только ниже их места объявления и ровно в их блоке (и во вложенных в нем).
-
а вообще, господа, - когда угар веселья прошел.. может кто то ответит мне.. что мы хотим добиться (кроме развлекалова ) ?
Ну, у меня два направления тут:
1) Рассмотреть варианты как снизить психологический порог вхождения для Оберона (фактический порог и так низок, но народ шугается синтаксиса который у них одновременно ассоциируется с досом и коболом (капс)). Причем сделать это не меняя грамматики, изменив только синтаксис. Язык остается тем же самым. Практика показывает, что народ падок на синтаксис питона. Почему бы и нет? Можно за EBNF'ить похожий синтаксис не меняя ядро грамматики (и тем более не трогая семантику).
2) Рассмотреть возможный пакет дополнений к Оберону, множество маленьких аккуратных дополнений которые могут сделать программирование на нем приятней, а следовательно и надежней. Но тут есть нюанс - до тех пор пока не напишешь на языке хотя бы тысяч 20 строк кода, обсуждать и думать в эту сторону продуктивно не получится. Просто потому что будешь туда тащить свои привычки из других языков. Причем эти 20к строк должны быть про прикладную задачу, а не про очередной компилятор оберона.
-
2.В Обероне переменные определяемые в секции VAR можно считать создаваемыми либо перед выполнением программы, либо в момент вызова процедуры.. и это для ряда задач БЛАГО, в СИ это не так...
В Си и С++ это как раз так.
Точнее, тут нужно уточнить что значит "создаются". Память под них выделяется на стеке в момент вызова функции. А использовать их можно только ниже их места объявления и ровно в их блоке (и во вложенных в нем).
Алексей, вы говорите про техническую сторону дела.. я про логическую (высокоуровневую) - вот эта строчка "А использовать их можно только ниже их места объявления и ровно в их блоке (и во вложенных в нем)." - на уровне "ящечной" аналогии эквивалентна.. следующему- переменная появилась (как емкость в которую можно заносить значения) в момент ее определения в каком-то месте (блока) и существует пока мы не выйдем из этого блока.
-
2.В Обероне переменные определяемые в секции VAR можно считать создаваемыми либо перед выполнением программы, либо в момент вызова процедуры.. и это для ряда задач БЛАГО, в СИ это не так...
В Си и С++ это как раз так.
Точнее, тут нужно уточнить что значит "создаются". Память под них выделяется на стеке в момент вызова функции. А использовать их можно только ниже их места объявления и ровно в их блоке (и во вложенных в нем).
Алексей, вы говорите про техническую сторону дела.. я про логическую (высокоуровневую) - вот эта строчка "А использовать их можно только ниже их места объявления и ровно в их блоке (и во вложенных в нем)." - на уровне "ящечной" аналогии эквивалентна.. следующему- переменная появилась (как емкость в которую можно заносить значения) в момент ее определения в каком-то месте (блока) и существует пока мы не выйдем из этого блока.
Поэтому я и разделил твое "создаются" на два более точных значения. Ибо зачем гадать? :-)
Кроме того, в С89/90 это именно так как ты описываешь - переменные должны быть объявлены в начале функии, до первого statement'a не являющимся объявлением переменной. Кстати, на нем написано большенство приложений писаных на Си.
Это стало не так начиная с C99 и далее C12.
Ну а плюсы - совсем другая история.
-
Поэтому я и разделил твое "создаются" на два более точных значения. Ибо зачем гадать? :-)
Затем, что меня и достаточно многих людей программирование интересует в контексте решаемой задачи.. если для ее решения ДОСТАТОЧНО воспользоваться простыми моделями и средствами.. то нахрена мне нужно знать "два и более... точных значений" ;) - как будто других проблем мало..
-
Поэтому я и разделил твое "создаются" на два более точных значения. Ибо зачем гадать? :-)
Затем, что меня и достаточно многих людей программирование интересует в контексте решаемой задачи.. если для ее решения ДОСТАТОЧНО воспользоваться простыми моделями и средствами.. то нахрена мне нужно знать "два и более... точных значений" ;) - как будто других проблем мало..
Ну, э. Меня тоже интересует в контексте решаемой задачи. И это в некоторых случаях принципиально важно в какой момент времени на стеке будет выделена память под массив со 100500 элементами.
Ну, а вообще, на этом форуме, в отличие от оборонкоре, высказав свое суждение всегда можно напороться на ответ презренного профессионала, который тонко разбирается в сортах этого дерьма :-)
-
Так нужна секция VAR или лучше как в С?
-
Так нужна секция VAR или лучше как в С?
Как в КАКОМ Си?
-
Ну, э. Меня тоже интересует в контексте решаемой задачи. И это в некоторых случаях принципиально важно в какой момент времени на стеке будет выделена память под массив со 100500 элементами.
Ну, а вообще, на этом форуме, в отличие от оборонкоре, высказав свое суждение всегда можно напороться на ответ презренного профессионала, который тонко разбирается в сортах этого дерьма :-)
1. Язык Оберон - не определяет реализацию с нужной вам точностью - соответственно НЕ ПОДХОДИТ(но может подойти его конкретная реализация). Задачи бывают разные... ЯВУ бывают разные... одни подходят для решения задачи другие нет, одни плохо подходят другие хорошо, третьи плохо.. но есть сторонние библиотеки нивелирующие "плохость" - судить о "плохости" яп на основании какой то задачи можно.. но суждение будет частным...
2. Да и там это тоже было..дело вот в чем.. для задач , решаемых коровятами с помощью КП - эти вопросы не существенны..- но это не значит, что КП даже для таких задач оптимальный выбор, или что эти задачи просты (проще тех которые стоят перед вами)... а мнение "презренного профессионала" (помимо того что оно давит на больные мозоли) им просто чужеродно (ибо непонятно).
-
Так нужна секция VAR или лучше как в С?
Как в КАКОМ Си?
Тогда так вопрос: секция VAR или объявление переменных в любом месте внутри блока с использованием ниже объявления?
-
Так нужна секция VAR или лучше как в С?
Как в КАКОМ Си?
Тогда так вопрос: секция VAR или объявление переменных в любом месте внутри блока с использованием ниже объявления?
Почему не рассматривается объявление переменных вначале процедуры без секции var?
Кроме того, блоков в Обероне нет. Это не Алгол и не Паскаль и не Си.
-
Почему не рассматривается объявление переменных вначале процедуры без секции var?
Кроме того, блоков в Обероне нет. Это не Алгол и не Паскаль и не Си.
"Секцию var" рассматриваем и просто как объявление переменных вначале процедуры и как, собственно, выделенную ключевым слов VAR. Если избавляемся от вара и бегина, нужно ли как-то отделять объявление от остального тела процедуры, к примеру ";"?
-
Почему не рассматривается объявление переменных вначале процедуры без секции var?
Кроме того, блоков в Обероне нет. Это не Алгол и не Паскаль и не Си.
"Секцию var" рассматриваем и просто как объявление переменных вначале процедуры и как, собственно, выделенную ключевым слов VAR. Если избавляемся от вара и бегина, нужно ли как-то отделять объявление от остального тела процедуры, к примеру ";"?
; - не годится. Слабо устойчиво к опечаткам, и увеличит WTF per minute.
Я хотел было предложить такое:
proc S(X : array of real) : real
s : real
e : real
i : integer
----
s := 0.0
e := E(x)
i := 0
while i # len(X)
s := s + (X[i]-e)*(X[i]-e)
inc(i)
return Math.sqrt(s)
Но вспомнил про ма-аленький такой нюанс - мы зациклились на VAR-секции, при этом абсолютно забыв про CONST и TYPE секции, а также про безымянную секцию (но которая также до BEGIN'а) для вложенных процедур.
-
Но вспомнил про ма-аленький такой нюанс - мы зациклились на VAR-секции, при этом абсолютно забыв про CONST и TYPE секции, а также про безымянную секцию (но которая также до BEGIN'а) для вложенных процедур.
:D вы не это забыли.. вы забыли то, что подпрограмма есть всего лишь отображение на язык программирования - понятия вспомогательный алгоритм... который отличается от основного лишь тем... что вспомогателен ( в контексте основной задачи) - а следовательно может обладать ВСЕМИ признаками основного (в том числе иметь свои вспомогательные алгоритмы)... соответственно и хорошо спроектированный язык должен давать как минимум ТАКИЕ ЖЕ возможности для отображений(подпрограмм)....- вот это есть часть восприятия яп с позиции решаемой внешней задачи...
-
вспомнил про ма-аленький такой нюанс - мы зациклились на VAR-секции, при этом абсолютно забыв про CONST и TYPE секции, а также про безымянную секцию (но которая также до BEGIN'а) для вложенных процедур.
Ну так просто последовательно объявляем константы, типы, переменные, вложенные процедуры без ключевых слов VAR, CONST и TYPE. Можно обойтись вообще без разделительного знака - компилятор и так легко определит, где закончилась секция объявления.
Что насчет объявления с возможностью инициализации?
proc S(X : array of real) : real
s, e: real:=0.0, E(x)
i : int:=0
while i # len(X)
s := s + (X[i]-e)*(X[i]-e)
inc(i);
return Math.sqrt(s)
end S;
-
вспомнил про ма-аленький такой нюанс - мы зациклились на VAR-секции, при этом абсолютно забыв про CONST и TYPE секции, а также про безымянную секцию (но которая также до BEGIN'а) для вложенных процедур.
Ну так просто последовательно объявляем константы, типы, переменные, вложенные процедуры без ключевых слов VAR, CONST и TYPE. Можно обойтись вообще без разделительного знака - компилятор и так легко определит, где закончилась секция объявления.
Компилятор да, а программист, не знакомый с языком, сгенерирует кучку кирпичей разбирая ошибки компиляции. Затем придет на форум, обложит всех матами и пойдет дальше писать на каком-нибудь богомерзком питоне.
-
Тогда нужно все оставлять: type, var, const тогда вероятность ошибки будет минимальной, да и порог вхождения тоже.
-
Тогда нужно все оставлять: type, var, const тогда вероятность ошибки будет минимальной, да и порог вхождения тоже.
В текущем синтаксисе тоже есть проблема - не очевидно, что порядок секций type, var, const имеет значение (точнее, что есть Единственно Верный Порядок)
-
Тогда нужно все оставлять: type, var, const тогда вероятность ошибки будет минимальной, да и порог вхождения тоже.
В текущем синтаксисе тоже есть проблема - не очевидно, что порядок секций type, var, const имеет значение (точнее, что есть Единственно Верный Порядок)
очевидна... ее и заучивать не надо..(она вполне определяется алгоритмом решения задачи) ;)
-
В текущем синтаксисе тоже есть проблема - не очевидно, что порядок секций type, var, const имеет значение (точнее, что есть Единственно Верный Порядок)
Тогда, может, заменим type, var, const на универсальное, скажем, declare, где объявления делаем в произвольном порядке?
-
В текущем синтаксисе тоже есть проблема - не очевидно, что порядок секций type, var, const имеет значение (точнее, что есть Единственно Верный Порядок)
Тогда, может, заменим type, var, const на универсальное, скажем, declare, где объявления делаем в произвольном порядке?
:) а вы считаете, что то что обьявляется в секциях type, var, const - одно и тоже?
-
В текущем синтаксисе тоже есть проблема - не очевидно, что порядок секций type, var, const имеет значение (точнее, что есть Единственно Верный Порядок)
Тогда, может, заменим type, var, const на универсальное, скажем, declare, где объявления делаем в произвольном порядке?
Мне не кажется это хорошей идеей.
Как правильно сделать - пока не знаю. Тут думать надо. Просто влепить решение из одного из других распространенных ЯП тут не прокатит.
-
В текущем синтаксисе тоже есть проблема - не очевидно, что порядок секций type, var, const имеет значение (точнее, что есть Единственно Верный Порядок)
Тогда, может, заменим type, var, const на универсальное, скажем, declare, где объявления делаем в произвольном порядке?
Мне не кажется это хорошей идеей.
я бы сказал даже гениальной.. - если тип данных это схема по которой создается переменная - великолепная идея - в строготипизированном яп = традиционно реализуемым однопроходным компилятором дать человеку, который не понимает разницу между типом , переменной и значениями, возможность вначале обьявить переменную а лишь потом обьявить ее тип
Vartovyj - извините, конечно - но может вам вначале стоит разобраться хотя бы с базовыми понятиями информатики?
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
Дальний порядок не важен, человек его не ощущает. Ближний порядок важен. Ближний - это тот, который умещается на экране. Это раз.
Два - отношение между двумя функциями не то же самое, что отношение между переменной, типом и statement'ом.
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
не говорите фигню.. если одна процедура зависит от другой, то последняя должна быть определена раньше.. либо использоваться forward -метка...
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
не говорите фигню.. если одна процедура зависит от другой, то последняя должна быть определена раньше.. либо использоваться forward -метка...
Только вот в Обероне нет forward-меток :-)
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
не говорите фигню.. если одна процедура зависит от другой, то последняя должна быть определена раньше.. либо использоваться forward -метка...
Только вот в Обероне нет forward-меток :-)
а ^ - что такое?
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
не говорите фигню.. если одна процедура зависит от другой, то последняя должна быть определена раньше.. либо использоваться forward -метка...
Только вот в Обероне нет forward-меток :-)
а ^ - что такое?
Разименовывание указателя? ;-)
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
не говорите фигню.. если одна процедура зависит от другой, то последняя должна быть определена раньше.. либо использоваться forward -метка...
Только вот в Обероне нет forward-меток :-)
а ^ - что такое?
Разименовывание указателя? ;-)
:o даже после определения заголовка функции?
-
:o даже после определения заголовка функции?
После заголовка функции это ставить нельзя.
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
ProcedureDeclaration = ProcedureHeading ";" ProcedureBody ident.
ProcedureHeading = PROCEDURE identdef [FormalParameters].
ProcedureBody = DeclarationSequence [BEGIN StatementSequence]
[RETURN expression] END.
DeclarationSequence = [CONST {ConstDeclaration ";"}]
[TYPE {TypeDeclaration ";"}]
[VAR {VariableDeclaration ";"}]
{ProcedureDeclaration ";"}.
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
не говорите фигню.. если одна процедура зависит от другой, то последняя должна быть определена раньше.. либо использоваться forward -метка...
Да ладно вам. У нас в одынэсах произвольный порядок и норм. Компилятору сложнее... да. Но человеку так удобнее. :)
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
не говорите фигню.. если одна процедура зависит от другой, то последняя должна быть определена раньше.. либо использоваться forward -метка...
Да ладно вам. У нас в одынэсах произвольный порядок и норм. Компилятору сложнее... да. Но человеку так удобнее. :)
Компилятору пофиг (если это не компилятор Вирта).
-
Ну да в принципе. Мешает то только однопроходность.
-
После заголовка функции это ставить нельзя.
тык это в 07...
-
После заголовка функции это ставить нельзя.
тык это в 07...
Дык да. Дефолтный оберон - самый свежий Оберон от Вирта.
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
Дальний порядок не важен, человек его не ощущает. Ближний порядок важен. Ближний - это тот, который умещается на экране. Это раз.
Про порядки не понял. Как мне поможет порядок процедур? У меня в голове эта категория пылью покрылась с тех пор как стал одынэсником. ;D
клац F12 и я в нужной процедуре...
клац ctrl+- и я вернулся обратно...
клац ctrl+alt+p и я созерцаю навигатор по процедурам...
А вы мне тут про технику метания каменного топора... ;D
-
DIzer, с другой стороны произвольный порядок объявления процедур ведь нормально воспринимается. ;)
ps Хотя я с вами согласен.
pps Ветка трэшовая эта, аж мурашки по коже ;D
Дальний порядок не важен, человек его не ощущает. Ближний порядок важен. Ближний - это тот, который умещается на экране. Это раз.
Про порядки не понял. Как мне поможет порядок процедур? У меня в голове эта категория пылью покрылась с тех пор как стал одынэсником. ;D
клац F12 и я в нужной процедуре...
клац ctrl+- и я вернулся обратно...
клац ctrl+alt+p и я созерцаю навигатор по процедурам...
А вы мне тут про технику метания каменного топора... ;D
Я ровно про это и написал. Между процедурами расстояние большое, следовательно порядок их не важен.
-
После заголовка функции это ставить нельзя.
тык это в 07...
Дык да. Дефолтный оберон - самый свежий Оберон от Вирта.
да ну.. :) - я еще не одной успешной (если это слово вообще можно применять к Оберонам ) коммерческой реализации не видел, где бы не было расширений "эталона".. что КП, что XDS ... вообщем херня все это.. скажем так... пока фиксирую в очередной раз неспособность конструктивно говорить на тему топика... предлагаю отложить это дело...
-
Я ровно про это и написал. Между процедурами расстояние большое, следовательно порядок их не важен.
Странно. Я ровно наоборот понял ;D
Пятница...
Пардонте ;)
-
А смысл в этом. Если процедура использует вызов другой процедуры, значит её нужно написать раньше. Даже если так можно писать, какой в этом смысл? Или сама возможность греет зимой, особенно гото в 1с? :D
-
А смысл в этом. Если процедура использует вызов другой процедуры, значит её нужно написать раньше. Даже если так можно писать, какой в этом смысл?
Взаимная рекурсия.
-
А смысл в этом. Если процедура использует вызов другой процедуры, значит её нужно написать раньше.
Почему это?
Вот два противостоящих подхода к разработке: снизу вверх (из кирпичиков собираем здание -- подход форта) и сверху вниз (пошаговое уточнение -- то, к чему призывал Вирт, но в своих языках так и не реализовал).
Мне лично больше нравится подход "сверху вниз"...
-
Это ж надо, сколько понаписывали:)
Все очень просто: что раньше относительно другого используется, то раньше и объявляется, а остальное, независимое - в произвольном порядке. Тоесть, никакой разницы нет так:
N=10
a: int
или так:
a: int
N=10
-
Несколько идей, насчет избавления от end:
процедуру всегда завершаем return---; с параметрами или без
тоже для конструкции if---then---else---;
-
Рускоязычные идентификаторы (и ключевые слова) лично мною также очень плохо воспринимаются.
И не удивительно. Сказывается "винегет" русских кодировок во второй половине прошлого века.
-
... А почему в языке (общего назначения) должен быть именно zerobased - уже обсуждалось.
Лично я тоже ЗА zerobased. Но есть одно НО. Исторически так сложилось, что математики (падлы :) ) индексируют элементы матриц с единицы. Это сильно диссонирует с правильными массивами в Обероне.
-
Рускоязычные идентификаторы (и ключевые слова) лично мною также очень плохо воспринимаются.
И не удивительно. Сказывается "винегет" русских кодировок во второй половине прошлого века.
Да нет, я просто код с кириллицей не воспринимаю. Мозг уходит в режим чтения художественной литературы, логика отключается.
-
... А почему в языке (общего назначения) должен быть именно zerobased - уже обсуждалось.
Лично я тоже ЗА zerobased. Но есть одно НО. Исторически так сложилось, что математики (падлы :) ) индексируют элементы матриц с единицы. Это сильно диссонирует с правильными массивами в Обероне.
1. чего уж одно но... многие так делают, математики, детишки в школе, студенты (не фошиствующие baby-рептилоиды), аффторы книг по алгоритмике...
2. ;D ;D А вы не задумывались над тем что противоположная точка зрения намного популярнее?
-
2. ;D ;D А вы не задумывались над тем что противоположная точка зрения намного популярнее?
Популярность - довольно зыбкий критерий.
-
и что?
-
valexey_u, лечится трёхдневным написанием кода с кириллицей. Это банальная фобия без привычки.
-
valexey_u, лечится трёхдневным написанием кода с кириллицей. Это банальная фобия без привычки.
+1
-
и что?
Я к тому, что сегодня одно популярно, завтра - другое.
Например, популярность использования кириллицы в программировании, ИМХО, неуклонно растёт (на постсоветском пространстве, разумеется).
-
и что?
Я к тому, что сегодня одно популярно, завтра - другое.
Например, популярность использования кириллицы в программировании, ИМХО, неуклонно растёт (на постсоветском пространстве, разумеется).
а если взаимотсос с забугорниками, сырцы клиенту, или публикация какая? кроме того вроде я говорил про индексацию с произвольного значения
-
Собственно, число русскоговорящего населения уже превысило 300 млн. во всём мире, обойдя испаноговорящих. Пора уже отказываться от "поравалить"-пораженческих веяний и начинать уважать свой язык и культуру. Он ничем не хуже англосаксонских.
-
Собственно, число русскоговорящего населения уже превысило 300 млн. во всём мире, обойдя испаноговорящих. Пора уже отказываться от "поравалить"-пораженческих веяний и начинать уважать свой язык и культуру. Он ничем не хуже англосаксонских.
для программирования хуже... и надо иметь мужество признать это...
-
Собственно, число русскоговорящего населения уже превысило 300 млн. во всём мире, обойдя испаноговорящих. Пора уже отказываться от "поравалить"-пораженческих веяний и начинать уважать свой язык и культуру. Он ничем не хуже англосаксонских.
для программирования хуже... и надо иметь мужество признать это...
Смотря для какого программирования
-
Мне лично больше нравится подход "сверху вниз"...
Это подход.. крутых, либо начинающих, либо тех которые решают самостоятельную задачу в пренебрежении взаимодействием (или оно слабое, или четкоопределенное) с внешними миром... вы себя какому виду относите?
-
для программирования хуже... и надо иметь мужество признать это...
А что мне признавать? Я в рамках учебного курса попробовал и не нашёл отличий. Точно так же, когда размышлял на тему кустарных языков и прикидывал синтаксис, то пробовал и кириллицу. Повторюсь, это фобии. Англоговорящие такими не страдают. И не читают код как произведение художественное.
-
Собственно, число русскоговорящего населения уже превысило 300 млн. во всём мире, обойдя испаноговорящих. Пора уже отказываться от "поравалить"-пораженческих веяний и начинать уважать свой язык и культуру. Он ничем не хуже англосаксонских.
для программирования хуже... и надо иметь мужество признать это...
Смотря для какого программирования
любого - другой принцип словообразования, большее число слов соответствующих различным понятиям.. как результат комментарии и идентификаторы на 30-50% короче..- уж вам то "профессиональному кодеру, знающему о боли в кистях " - это должно быть понятно
-
valexey_u, лечится трёхдневным написанием кода с кириллицей. Это банальная фобия без привычки.
Не лечится. Я предпочитаю иметь много слов с узким значением, чем мало слов с неоднозначным значением. Поэтому программировать я предпочитаю на латинице, ведь в этом случае для меня for это не кусок естественного языка с двумя десятками значений (http://slovari.yandex.ru/for/%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4/#lingvo/), а четко обозначенная конструкция языка программирования. Никакие мусорные аллюзии из естественных языков в голову не лезут.
Поэтому мне проще изучать ЯП и программировать чем кому-нибудь для кого английский - родной. И терять это преимущество я не собираюсь.
Поэтому русские ключевые слова - зло. Они вводят в заблуждение и повышают порог вхождения.
-
кроме того вроде я говорил про индексацию с произвольного значения
Да, я это помню. Если я правильно Вас понял, Вы выразились в пользу индексации с единицы, аргументируя это тем, что такой способ индексации популярнее. В ответ я возразил, что популярность - это плохой критерий. Про кириллицу - это был просто пример непостояннства такого критерия оценки.
-
Поэтому русские ключевые слова - зло. Они вводят в заблуждение и повышают порог вхождения.
нет не зло.. на начальном этапе дополнительная опора на знакомые ассоциации - это лучше чем ничего..
-
кроме того вроде я говорил про индексацию с произвольного значения
Да, я это помню. Если я правильно Вас понял, Вы выразились в пользу индексации с единицы, аргументируя это тем, что такой способ индексации популярнее. В ответ я возразил, что популярность - это плохой критерий. Про кириллицу - это был просто пример непостояннства такого критерия оценки.
да ну..вы всерьез считаете что в этом направление может что - измениться? ;D не вижу никаких предпосылок
-
Поэтому русские ключевые слова - зло. Они вводят в заблуждение и повышают порог вхождения.
нет не зло.. на начальном этапе дополнительная опора на знакомые ассоциации - это лучше чем ничего..
Хуже. Потому, что это ложные ассоциации.
Прекрасно помню, как в школе на уроке информатики одна девочка очень хорошо знала английский, но это ей ну никак не помогало понять что же это за хрень такая - "for". Ну, "для", и что?
-
valexey_u, Вы как-то забываете, что на английском говорят и читают больше людей. И они в курсе множества значений слова for. И это их не напрягает, не вводит в заблуждение и не повышает порог вхождения.
В общем-то армия программистов 1С - живой пример, разрушающий иллюзии. Собственно, студентам вообще всегда было всё равно, какой язык использовать. Школьникам тоже, родной даже удобнее. Так с какого момента должен появиться загадочный порог вхождения? С того, что ПЕРЕМ будет вместо VAR? Или Вы полагаете, что в английском легко придумать имя переменной, отвечающее сложной проблемной области?
-
Хуже. Потому, что это ложные ассоциации.
Лучше -в отличие от вас - я РАБОТАЮ (а не только вижу) с людьми после школ, а ассоциации правильные - я столько видел ошибок изза назначений переменным имен bb, m,ffr - только потому, что не могут иначе(собачий помогает, но не так сильно)
-
Или Вы полагаете, что в английском легко придумать имя переменной, отвечающее сложной проблемной области?
ЛЕГЧЕ.. и однозначно это будет короче -причины я вам назвал..
-
valexey_u, Вы как-то забываете, что на английском говорят и читают больше людей. И они в курсе множества значений слова for. И это их не напрягает, не вводит в заблуждение и не повышает порог вхождения.
А они просто не знают что бывает иначе :-) Они привыкли к этому кактусу.
В общем-то армия программистов 1С - живой пример, разрушающий иллюзии.
Как раз 1Совцы - живое подтверждение тому о чем я пишу :-) Про них слагают уже легенды и анекдоты (примерно также как про индусов).
Собственно, студентам вообще всегда было всё равно, какой язык использовать. Школьникам тоже, родной даже удобнее.
Язык они будут использовать паскаль, си или что-то еще. Но никак не русский или английский. Я прекрасно помню, что когда я был школьником, и изучал программирование - я абсолютно не владел английским (четкая тройка стремящаяся временами к двойке). Соответственно "for" для меня стал тогда сразу четким и однозначным - конкретной сишной конструкцией. Без аллюзий. А вот народ знавший английский - путался.
Так с какого момента должен появиться загадочный порог вхождения? С того, что ПЕРЕМ будет вместо VAR? Или Вы полагаете, что в английском легко придумать имя переменной, отвечающее сложной проблемной области?
С самого начала загадочный порог вхождения проявляется. Причем потом, после того как первое усилие совершили и через порог перевалили, появляется еще и трение (кривые ассоциации постоянно приводят к неверным умозаключениям).
А в моей сложной предметной области (НЕ программирование) на английском переменные называть проще, потому как рускоязычных терминов просто нет, либо они калька с английского, либо они ужасны. Ну и подавляющее большенство литературы (научные статьи, патенты и так далее) естественно на английском.
-
да ну..вы всерьез считаете что в этом направление может что - измениться? ;D не вижу никаких предпосылок
На мой взгляд, положительные тенденции имеются. Весь вопрос в том, как далеко они зайдут.
Кстати, число ноль тоже не сразу открыли. Теперь вот тормозят начинать индексацию с него :D
-
А они просто не знают что бывает иначе :-) Они привыкли к этому кактусу.
Надеюсь, когда-нибудь такое и с русским языком произойдёт.
Я прекрасно помню, что когда я был школьником, и изучал программирование - я абсолютно не владел английским (четкая тройка стремящаяся временами к двойке). Соответственно "for" для меня стал тогда сразу четким и однозначным - конкретной сишной конструкцией. Без аллюзий. А вот народ знавший английский - путался.
У меня с английским всегда было хорошо, включая разговорный. Поэтому я знал значения for. И меня нисколько это не смутило и не смущает. Так что ваш личный опыт безусловно ценен, но его нельзя проецировать на всех. Знания языков должно быть хорошим, к путанице приводить не должно, т.к. все языки неоднозначны и не формализованы. Кому это мешает?
А в моей сложной предметной области (НЕ программирование) на английском переменные называть проще, потому как рускоязычных терминов просто нет, либо они калька с английского, либо они ужасны. Ну и подавляющее большенство литературы (научные статьи, патенты и так далее) естественно на английском.
Ну так выход может быть только один. Развивать свой язык, повышать его популярность. Будут и статьи и термины.
-
А они просто не знают что бывает иначе :-) Они привыкли к этому кактусу.
Надеюсь, когда-нибудь такое и с русским языком произойдёт.
Очень надеюсь, что нет. Я слишком люблю русский язык. Не надо его смешивать с языками программирования. Ни ему ни им это на пользу не пойдет. Впрочем, от англоязычных ключевых слов тоже неплохо бы было отказаться. Вон, в haskell'e их почти и нет :-)
А в моей сложной предметной области (НЕ программирование) на английском переменные называть проще, потому как рускоязычных терминов просто нет, либо они калька с английского, либо они ужасны. Ну и подавляющее большенство литературы (научные статьи, патенты и так далее) естественно на английском.
Ну так выход может быть только один. Развивать свой язык, повышать его популярность. Будут и статьи и термины.
Да не язык надо развивать, а науку/эти предметные области надо развивать в стране. По CS мы отстали лет на 20ть, по медицине и dsp - лет на 10 (минимум).
-
Мне лично больше нравится подход "сверху вниз"...
Это подход.. крутых, либо начинающих, либо тех которые решают самостоятельную задачу в пренебрежении взаимодействием (или оно слабое, или четкоопределенное) с внешними миром... вы себя какому виду относите?
Вапще-то это стандартный подход хаскеллеров.
-
valexey_u, Вы как-то забываете, что на английском говорят и читают больше людей. И они в курсе множества значений слова for. И это их не напрягает, не вводит в заблуждение и не повышает порог вхождения.
В общем-то армия программистов 1С - живой пример, разрушающий иллюзии. Собственно, студентам вообще всегда было всё равно, какой язык использовать. Школьникам тоже, родной даже удобнее. Так с какого момента должен появиться загадочный порог вхождения? С того, что ПЕРЕМ будет вместо VAR? Или Вы полагаете, что в английском легко придумать имя переменной, отвечающее сложной проблемной области?
Вот ключевой момент!
Berserker меня опередил.
Писать прикладуху, подобную 1С-ной на ангельском смерть. Ибо его в этом случае нужно знать как родной. А таких программеров в России просто нет. (за редким исключением)
Наша прикладная область - это десятки тысяч терминов. Но они легко воспринимаются ибо язык родной.
Кроме того у 1сников не принято сокращать имена переменных. Ибо нужно очень быстро понимать что происходит в конкретном куске кода.
У нас парень работает, который до 1С только пару лаб на трупе паскаля сделал. Опыта нет но котелок хорошо варит. Когда он проработал меньше полугода, ему попалась задачка отдебажить и отрефакторить модуль 10000 строк кода. Справился без проблем за 3 дня. Уменьшил количество кода до 4000 строк.
-
Мне лично больше нравится подход "сверху вниз"...
Это подход.. крутых, либо начинающих, либо тех которые решают самостоятельную задачу в пренебрежении взаимодействием (или оно слабое, или четкоопределенное) с внешними миром... вы себя какому виду относите?
Вапще-то это стандартный подход хаскеллеров.
понятно, как у новичков... с учебными задачами (слабо соотносящихся с реальностью)
-
Вот ключевой момент!
Berserker меня опередил.
Писать прикладуху, подобную 1С-ной на ангельском смерть. Ибо его в этом случае нужно знать как родной. А таких программеров в России просто нет. (за редким исключением)
Наша прикладная область - это десятки тысяч терминов. Но они легко воспринимаются ибо язык родной.
Кроме того у 1сников не принято сокращать имена переменных. Ибо нужно очень быстро понимать что происходит в конкретном куске кода.
У нас парень работает, который до 1С только пару лаб на трупе паскаля сделал. Опыта нет но котелок хорошо варит. Когда он проработал меньше полугода, ему попалась задачка отдебажить и отрефакторить модуль 10000 строк кода. Справился без проблем за 3 дня. Уменьшил количество кода до 4000 строк.
нет тут никакого ключевого момента, если бы 1С ники были англоговорящими - у них получилось бы то же самое... и уложились они бы в 3000 строк... в силу ОБЪЕКТИВНЫХ особенностей.. а не всякой фигни...
-
Ну тык я ровно это и сказал. Писать прикладуху на родном гораздо проще. Что у нас, что за бугром. За бугром многие вообще не представляют что значит писать на чужом языке :)
-
Ну тык я ровно это и сказал. Писать прикладуху на родном гораздо проще. Что у нас, что за бугром. За бугром многие вообще не представляют что значит писать на чужом языке :)
конечно (но для англоязычных на своем языке.. ваши 1с были бы короче на те же 30-50 % без всякой потери наглядности - я говорю про это.. ).. хотя Алексей безусловно прав.. что конструкции - это по своей сути формы.. но даже формы запоминаются проще (у большинства людей) - если им полностью соответствует некоторая знакомая с детства ассоциация..... хмм ;D ;D ;D ;D тогда получается, что самый подходящий язык - китайский.. :) :) :) :) ...
-
В идеале, для программирования должен быть универсальный символьный язык, возможно как расширение математического, так как тесно с ним переплетается. В юникоде места хватит.
-
если бы 1С ники были англоговорящими - у них получилось бы то же самое... и уложились они бы в 3000 строк... в силу ОБЪЕКТИВНЫХ особенностей.. а не всякой фигни...
Они бы уложились в те же 4000 строк, но строки были бы короче.
-
если бы 1С ники были англоговорящими - у них получилось бы то же самое... и уложились они бы в 3000 строк... в силу ОБЪЕКТИВНЫХ особенностей.. а не всякой фигни...
Они бы уложились в те же 4000 строк, но строки были бы короче.
согласен - более корректно... :) - но один черт пиндо- Ilovb- бы экономил на дорогущем пиндомедлечении
-
2 DIzer, Peter Almazov
Я акцент там хотел не на 4000 тысячах поставить, а на 3 днях...
А по поводу 1С чую есть недопонимание.
Цепочка логическая должна быть такая:
Термины прикладной области -> Ключевые слова языка.
Т.е. написание ключевых слов на русском это следствие того, что необходимо писать термины на русском.
Так сделали чтобы НЕ ПЕРЕКЛЮЧАТЬ РАСКЛАДКУ.
Остальное фантазии.
-
В идеале, для программирования должен быть универсальный символьный язык, возможно как расширение математического, так как тесно с ним переплетается. В юникоде места хватит.
не поможет.. - правильно подобранные идентификаторы - дают очень много.. а поскольку они идут из предметной области задачи..(которая в пределе окружающий нас мир) -создание такого (специального) языка дело бесперспективное..
-
2 DIzer, Peter Almazov
Я акцент там хотел не на 4000 тысячах поставить, а на 3 днях...
А по поводу 1С чую есть недопонимание.
Цепочка логическая должна быть такая:
Термины прикладной области -> Ключевые слова языка.
Т.е. написание ключевых слов на русском это следствие того, что необходимо писать термины на русском.
Так сделали чтобы НЕ ПЕРЕКЛЮЧАТЬ РАСКЛАДКУ.
Остальное фантазии.
нет никакого недопонимания - разве в англо -1с для англо- ilovb - что то было бы по другому (за исключением, количества нажатий)?
-
Пиктограммы, символы гораздо сильнее буквенных конструкций по восприятию.
-
Оберон не является достаточно высокоуровневым языком, где можно было бы писать компактно (скажем попробуйте ка в Обероне инициализировать массив константами - придется нарисовать 100500 присваиваний вместо одного присваивания как в других яызках).
Как решить вопрос?
-
Пиктограммы, символы гораздо сильнее буквенных конструкций по восприятию.
ну что же Vartovyj - будем считать , что новое направление вашего творчества определено... :) - тут уж вы точно сможете предоставить такое решение.. что никто здесь переплюнуть не сможет...
-
Термины прикладной области -> Ключевые слова языка.
Т.е. написание ключевых слов на русском это следствие того, что необходимо писать термины на русском.
Так сделали чтобы НЕ ПЕРЕКЛЮЧАТЬ РАСКЛАДКУ.
У тебя просто очень специфическая предметка - она тесно переплетена с нашим законодательством которое, в свою очередь, полно терминов-жаргонизмов на русском.
Если у меня в предметной области термины на латыни, значит ли это, что следует ключевые слова на латынь перевести?
Короче, мы сейчас договоримся до Алгола-68, который имел локализации (официальные) для ряда языков, в том числе и русского.
-
Оберон не является достаточно высокоуровневым языком, где можно было бы писать компактно (скажем попробуйте ка в Обероне инициализировать массив константами - придется нарисовать 100500 присваиваний вместо одного присваивания как в других яызках).
Как решить вопрос?
учить китайский...
-
нет никакого недопонимания - разве в англо -1с для англо- ilovb - что то было бы по другому (за исключением, количества нажатий)?
Количество нажатий сильно сокращается за счет автозавершения, а следовательно, выигрыш англо -1сника вряд ли существенен.
И я согласен, надо программировать на том языке, на каком знаешь предметную область (знал бы на английском, программировал бы на нем, а раз нет, то мне гораздо проще на русском)
-
Пиктограммы, символы гораздо сильнее буквенных конструкций по восприятию.
Ну, привет Algol-68 и APL :-)
-
Пиктограммы, символы гораздо сильнее буквенных конструкций по восприятию.
Серьезно... - посмотрите на Лисп (Схему) с его ( ) или Си { } -это символы, и насколько они выразительны в контексте этих языков?
-
Оберон не является достаточно высокоуровневым языком, где можно было бы писать компактно (скажем попробуйте ка в Обероне инициализировать массив константами - придется нарисовать 100500 присваиваний вместо одного присваивания как в других яызках).
Как решить вопрос?
Ввести возможность инициализации, как это сделано в Активном Обероне, хотя Модула-3 в этом плане мне нравится больше
-
Термины прикладной области -> Ключевые слова языка.
Т.е. написание ключевых слов на русском это следствие того, что необходимо писать термины на русском.
Так сделали чтобы НЕ ПЕРЕКЛЮЧАТЬ РАСКЛАДКУ.
У тебя просто очень специфическая предметка - она тесно переплетена с нашим законодательством которое, в свою очередь, полно терминов-жаргонизмов на русском.
Ну да специфическая. Но законодательство тут не при чем. Т.е. оно конечно умножает определенным коэффициентом... но не шибко.
Дело в другом. Вот представь себе, что нужно автоматизировать медицинское учреждение... или там военное например.
казарма, сержант, ефрейтор, полковник, кирзовые сапоги, прапорщик, наряд, средства индивидуальной защиты, табельное оружие, фуражка, шинель, мундир, знак отличия, автоматизированная станция 86Ж6 "Поле" и т.д. и т.п.
Хватит тебе твоего ангельского?
-
Оберон не является достаточно высокоуровневым языком, где можно было бы писать компактно (скажем попробуйте ка в Обероне инициализировать массив константами - придется нарисовать 100500 присваиваний вместо одного присваивания как в других яызках).
Как решить вопрос?
Может, ввести конструкторы массивов. Тогда можно будет записать:
a := [a 2; 3 -b] // массив 2х2
-
Игорь - отмотайте назад.. вчера мы уже до кортежей дошли... ;D
-
Может, ввести конструкторы массивов. Тогда можно будет записать:
a := [a 2; 3 -b] // массив 2х2
Хе... Переменные а и а не разделил, однако...
-
Игорь - отмотайте назад.. вчера мы уже до кортежей дошли... ;D
Да, смотрел по диагонали (многа букаф)
-
Игорь - отмотайте назад.. вчера мы уже до кортежей дошли... ;D
Да, смотрел по диагонали (многа букаф)
извиняйте - по китайски пока не могем( что бы было мало... иероглифов) ;D
-
Ввести возможность инициализации, как это сделано в Активном Обероне, хотя Модула-3 в этом плане мне нравится больше
В Сириусе идеи для модификации Оберона взяты с них?
-
Оберон не является достаточно высокоуровневым языком, где можно было бы писать компактно (скажем попробуйте ка в Обероне инициализировать массив константами - придется нарисовать 100500 присваиваний вместо одного присваивания как в других яызках).
Как решить вопрос?
Странно все это слушать. Есть же простой и универсальный (хотя и неказистый) способ конструирования любых значений средствами яыка. Через сторки.
Как-то так:
a := StringToMatrixOfInteger(
"[[1, 0, 0]," +
"[0, 1, 0]," +
"[0, 0, 1]]", 3, 3)
Конечно, инициализация происходит при загрузке, а не при компиляции.
А зачем еще в язык введены строки, как не для обработки текста программ?
-
Оберон не является достаточно высокоуровневым языком, где можно было бы писать компактно (скажем попробуйте ка в Обероне инициализировать массив константами - придется нарисовать 100500 присваиваний вместо одного присваивания как в других яызках).
Как решить вопрос?
Странно все это слушать. Есть же простой и универсальный (хотя и неказистый) способ конструирования любых значений средствами яыка. Через сторки.
Как-то так:
a := StringToMatrixOfInteger(
"[[1, 0, 0]," +
"[0, 1, 0]," +
"[0, 0, 1]]", 3, 3)
Конечно, инициализация происходит при загрузке, а не при компиляции.
А зачем еще в язык введены строки, как не для обработки текста программ?
За такое надо расстреливать без права воскрешения.
-
За такое надо расстреливать без права воскрешения.
А что я, я то что, я ничего. Вы на разработчиков ББ посмотрите, в модуле Strings они числа в строки и строки в числа гоняют процедурами IntToString, IntToStringForm, RealToString, RealToStringForm, StringToInt, StringToLInt, StringToReal. Это все они!
Я вот думаю, может вообще от числовых литералов избавиться, какие-то они не такие. И получать их конвертацией строк при компиляции. Будут одни строки.
Нет, лучше избавиться от строк, как-то они выбиваются из концепции, и путь будут одни числа (но не такие как сейчас) и литеры.
-
За такое надо расстреливать без права воскрешения.
А что я, я то что, я ничего. Вы на разработчиков ББ посмотрите, в модуле Strings они числа в строки и строки в числа гоняют процедурами IntToString, IntToStringForm, RealToString, RealToStringForm, StringToInt, StringToLInt, StringToReal. Это все они!
Я вот думаю, может вообще от числовых литералов избавиться, какие-то они не такие. И получать их конвертацией строк при компиляции. Будут одни строки.
Нет, лучше избавиться от строк, как-то они выбиваются из концепции, и путь будут одни числа (но не такие как сейчас) и литеры.
Я все же предпочитаю получить ошибку на этапе компиляции, а не на этапе работы приложения.
-
Я все же предпочитаю получить ошибку на этапе компиляции, а не на этапе работы приложения.
"Константы"-переменные все равно будут инициироваться при загрузке модуля, и результат их вычисления (включая ошибку) не будет зависеть от окружения, если их вычисление не опирается на импортируемые сущности. Достаточно одной проверочной загрузки модуля, чтобы обнаружить ошибку (модуль не загрузится).
А если имеются импортируемые константные операнды в выражении, то им даже подлинные константы при компиляции не проинициируются. Такие константы тоже должны инициироваться при загрузке модуля, с проверками наличия импортиуемых модулей, константности импортиуемых операндов, согласованности типов.
Правда в ББ мне не удается прокомпилировать модуль с выражением для константы, содержащим импортируемый операнд из несуществующиего модуля. А как же раздельная компиляция?
MODULE mmm;
IMPORT nnn(*symbol file of imported module not found*);
CONST a = nnn.a;
BEGIN
END mmm.
-
Я все же предпочитаю получить ошибку на этапе компиляции, а не на этапе работы приложения.
"Константы"-переменные все равно будут инициироваться при загрузке модуля, и результат их вычисления (включая ошибку) не будет зависеть от окружения, если их вычисление не опирается на импортируемые сущности. Достаточно одной проверочной загрузки модуля, чтобы обнаружить ошибку (модуль не загрузится).
Стоп. Какие такие "константы"-переменные применительно к Оберону? Они целиком и полностью известны на этапе компиляции.
-
Стоп. Какие такие "константы"-переменные применительно к Оберону? Они целиком и полностью известны на этапе компиляции.
Это переменные, которые имитируют константы - инициируются при загрузке модуля и в дальнейшем не изменяют свое значение.
-
Стоп. Какие такие "константы"-переменные применительно к Оберону? Они целиком и полностью известны на этапе компиляции.
Это переменные, которые имитируют константы - инициируются при загрузке модуля и в дальнейшем не изменяют свое значение.
Эмм.. А кто гарантирует что они действительно не будут изменяться?
-
Эмм.. А кто гарантирует что они действительно не будут изменяться?
Естественно, что программист, а кто еще? По крайней мере, можно ограничиться программистом модуля этой переменной, если он поставит ей метку экспорта только для чтения.
-
Эмм.. А кто гарантирует что они действительно не будут изменяться?
Естественно, что программист, а кто еще? По крайней мере, можно ограничиться программистом модуля этой переменной, если он поставит ей метку экспорта только для чтения.
Ну, э... Например компилятор. В других языках такое возможно.
Кстати. в Обероне вроде как нельзя переменные экспортировать не в read-only.
-
Что-то я сбился с фокуса дискуссии.
Утверждалось, что присвоение переменным фиксированных структурных значений слишком громоздское и ненаглядное по сравнению с конструкторами, которых в языке нет. А инициализация структурных констант вообще невозможна.
Я возразил: существующими средствами языка создание структурных фиксированных значений возможно почти также кратко и наглядно, как и через конструкторы. Оно возможно через строки. Строка - самый компактный конструктор, потому что лексический.
Конструктор-выражение отображаемое одной такой строкой не должно использовать имена полей (в конструкторах записей), идентификаторы и операции, а только лишь литеральные константы и подконструкторы - тогда значение выражения фиксированно его текстовым представлением. Впрочем, можно еще использовать предопределенные идентификаторы констант, функций и операций, т.к. возможно автономное распознание их значений.
Да, проверка внутренности этих строк на синтакис и допустимость значений невозможна при компиляции, как это имеет место для конструкторов. Но если нужно получить фиксированное (текстом строки) структурное значение, то проверка корректности задающей его константной строки возможна уже при загрузке, если проверка идет в теле модуля.
Впрочем, если конструктор-выражение содержит идентификаторы, то увы, оно отбражается более громоздко - конкатенацией подстрок, где подвыражения с идентификаторами преобразованы функцией в строчные значения. Замена конструкторам не полноценная.
Если это конструктор-выражение содержит только идентификаторы-константы, то отображающее его строковое выражение опять же имеет фиксированное значение, а его корректность проверяется при загрузке, если проверка идет в теле модуля.
Если содержит идентификаторы-переменные, то такое конструктор-выражение задает переменное структурное значение, а отображающее его строковое выражение при загрузке проверить на корректность уже нельзя.
Когда же я говорил об избавлении от числовых литералов и о выражении чисел через строки, это уже другая тема. Я имел ввиду изменение языка, когда преобразующие функции "строка в число" становятся предопределенными, и значит могут использоваться в константных выражениях.
Ну, э... Например компилятор. В других языках такое возможно.
Если нам нужно не просто компактное и наглядное получение фиксированных структурных значений, а именно создание константных структурных значений и введение структурных констант, да, в Оберонах это невозможно.
Если мы хотим, чтобы значения структурных объектов проверялись на фиксированность (постоянство) компилятором или хотя бы при загрузке, мы должны сделать идентификаторы этих объектов константами. А выражения для структурных значений этих констант должны использовать конструкторы структурных значений или предопределенные функции со структурными значениями.
Язык здесь требует расширения - конструкторами или преобразующими предопределенными функциями.
В варианте с преобразующими функциями, компактнее всего использовать строки.
Кстати. в Обероне вроде как нельзя переменные экспортировать не в read-only.
Я работаю только с КП в ББ, там можно.
-
Ввести возможность инициализации, как это сделано в Активном Обероне, хотя Модула-3 в этом плане мне нравится больше
В Сириусе идеи для модификации Оберона взяты с них?
Да
-
Правда в ББ мне не удается прокомпилировать модуль с выражением для константы, содержащим импортируемый операнд из несуществующиего модуля. А как же раздельная компиляция?
MODULE mmm;
IMPORT nnn(*symbol file of imported module not found*);
CONST a = nnn.a;
BEGIN
END mmm.
Похоже, что Вы путаете раздельную компиляцию с независимой компиляцией. Для раздельной компиляции по определению нужны символьные файлы всех импортируемых модулей. При желании об этом можно почитать у Н.Вирта "Построение компиляторов", гл. 15.
-
Что-то я сбился с фокуса дискуссии.
Утверждалось, что присвоение переменным фиксированных структурных значений слишком громоздское и ненаглядное по сравнению с конструкторами, которых в языке нет. А инициализация структурных констант вообще невозможна.
.....
Никто этого не утверждал.. я лично говорил о том, что не очень хорошо выглядит ПОЛНОЦЕННЫЙ кортеж , и не всегда возможна ПОЛНОЦЕННАЯ (с точки зрения приложения) инициализация переменных ПЕРЕД выполнением программы (подпрограммы) в секции VAR..
-
Похоже, что Вы путаете раздельную компиляцию с независимой компиляцией. Для раздельной компиляции по определению нужны символьные файлы всех импортируемых модулей. При желании об этом можно почитать у Н.Вирта "Построение компиляторов", гл. 15.
А мне почему-то казалось, что символьные файлы импортируемых модулей нужны только при загрузке, и что при компиляции импортируемые идентификаторы воспринимаются полностью абстрактно (типо промежуточное КС-представление модуля). А подлинная (JIT-) компиляция с проверкой типов идет только при загрузке. Теперь понятно. Никакого абстрактного промежуточного представления нет, сразу бинарный код.
Значит случай с константами вычисляемыми при загрузке отпадает. Так даже лучше.
Раз импортируемые константные операнды, входящие в выражение инициирующее местную константу, известны при компиляции, то значение самой местной константы будет при компиляции известно, проверено на корректность (ее выражение) и вычислено.
Так что значения аналогичных структурных констант (по факту представляемых переменными) также будут быть известны при компиляции (ибо не зависят от глобальных переменных и импортированных процедур), хотя проверяться на корректность (их выражения) и вычисляться они могут при загрузке (если инициируются в теле модуля), так как их выражения используют непредопределенные преобразующие функции.
Тогда ошибок при выполнении не возникнет. Так что
Я все же предпочитаю получить ошибку на этапе компиляции, а не на этапе работы приложения.
здесь порядок.
Преобразующая функция такова, что ее почти можно перевести в разряд предопределенных, так как она не использует (не читает, не изменяет) никаких непредопределенных нелокальных констант, типов, переменных и процедур, кроме структурного типа результата.
Вообще проблема конструкторов в том, что в паскаль-семействе языков эквивалентность типов не структурная. Поэтому конструкторы-выражения в силу их предопределенности не должны иметь типа, иначе их было бы невозможно присвоить объектам с типом введенным пользователем. Но в этом случае, в конструктор-выражениях нельзя будет использовать любые идентификаторы (они типизированы), а только лишь литеральные константы (числа, литеры, строки). Это очень сильное ограничение.
А в случае структурной эквивалентности типов пришлось бы делать все возможные типы предопределенными.
-
А мне почему-то казалось, что символьные файлы импортируемых модулей нужны только при загрузке, ...
При компиляции символьные файлы нужны для статической проверки типов.
Значит случай с константами вычисляемыми при загрузке отпадает. Так даже лучше.
Раз импортируемые константные операнды, входящие в выражение инициирующее местную константу, известны при компиляции, то значение самой местной константы будет при компиляции известно, проверено на корректность (ее выражение) и вычислено.
Так что значения аналогичных структурных констант (по факту представляемых переменными) также будут быть известны при компиляции (ибо не зависят от глобальных переменных и импортированных процедур), хотя проверяться на корректность (их выражения) и вычисляться они могут при загрузке (если инициируются в теле модуля), так как их выражения используют непредопределенные преобразующие функции.
При загрузке модуля никакие константы не вычисляются. В процессе компиляции производится свёртка констант, так что в объектном модуле (который и подлежит загрузке) никаких константных выражений уже нет. К тому же, память выделяется только под строковые константы (я про Оберон), а остальные константы компилятор размещает в регистрах проца (по месту использования). Таким образом, при загрузке инициализируются только строковые константы. Они по сути реализуются как переменные только для чтения. Остальные объявленные в модуле константы по факту (т.е. в процессе выполнения) используются как непосредственные константы. Это, кстати, одна из причин, почему в общем случае невозможно однозначно диззассемблировать машинные коды.
-
в объектном модуле (который и подлежит загрузке)
Суть в том, что объектный модуль создается при компиляции, а не при загрузке. Вот тебе и компиляция "на лету".
-
Вывод: подобная "дуальность" в языке - однозначное зло. А почему в языке (общего назначения) должен быть именно zerobased - уже обсуждалось.
"Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." — Stan Kelly-Bootle
-
Господа , а может нафиг мордовать Оберон - слишком много чести.. давайте ломать Рапиру? :D - так сказать грехопадение на основе исконно советской школы программирования... - весьма патриотично...
-
вот описание http://agat9.narod.ru/TECH/STAN_FIL/RAPIRA.HTM (http://agat9.narod.ru/TECH/STAN_FIL/RAPIRA.HTM)
-
Ахаха я чуть со стула не упал ;D ;D ;D
Этот документ предназначен для пользователей, участвующих в опытной
эксплуатации системы "ШКОЛЬНИЦА"...
;)
-
Господа , а может нафиг мордовать Оберон - слишком много чести.. давайте ломать Рапиру? :D - так сказать грехопадение на основе исконно советской школы программирования... - весьма патриотично...
Кстати, Рапира -- суперский язык же, в детстве я по ней тащился сильнее чем по лиспу!
-
Ахаха я чуть со стула не упал ;D ;D ;D
Этот документ предназначен для пользователей, участвующих в опытной
эксплуатации системы "ШКОЛЬНИЦА"...
;)
Жестоко :)
-
Ахаха я чуть со стула не упал ;D ;D ;D
Этот документ предназначен для пользователей, участвующих в опытной
эксплуатации системы "ШКОЛЬНИЦА"...
;)
ну да... даже не "ШКОЛЬНИК" - и не "БУДУЩИЙ 1с -ник" :D у одынэсников .. есть неисправимый недостаток... - слишком закомплексованы ( ну прям как наш премьер...)
-
Ахаха я чуть со стула не упал ;D ;D ;D
Этот документ предназначен для пользователей, участвующих в опытной
эксплуатации системы "ШКОЛЬНИЦА"...
;)
Народ, а нас за педофилию не того? А то по новым законам вполне этот документ может подпасть..
:-)
-
Ахаха я чуть со стула не упал ;D ;D ;D
Этот документ предназначен для пользователей, участвующих в опытной
эксплуатации системы "ШКОЛЬНИЦА"...
;)
Народ, а нас за педофилию не того? А то по новым законам вполне этот документ может подпасть..
:-)
тык систему же эксплуатируют.. с названием "Школьница"- грамотно заковыченную - а не Школьницу Рапирой понужают...
-
фууу какие вы испорченные ))
Кстати, там ещё и толи система, то ли язык Шпага была...
-
Что если придать циклу с for большую универсальность?
Помимо стандартного for...to...by...do...end; и того что раньше обсуждалось,
заменяем while...do...end; на for...do...end;
-
...
заменяем while...do...end; на for...do...end;
Вы плохо представляете себе их разницу...
1. Применяется когда количество итераций (повторений тела цикла) можно определить ДО выполнения итераций.
2. Второй - это количество определяется ВО ВРЕМЯ выполнения итераций...
-
... хотя , как ни странно, с точки зрения Оберона.. особой разницы нет (for реализуется через while).
-
1. for...to...by...do...end; - до выполнения, стандартный for
2. for...do...end; - во время выполнения, замена while
Позаимствовано с Go.
-
зачем... можно пользоваться одним while если неймется... вон Инфо21 таким образом мордовал(дует?) детишек, а Вирт одно время и вовсе исключал for из Оберона.. но потом вернул обратно.. как вы думаете почему? :D
-
Раньше мы уже обсуждали придание конструкциям с for значительно расширенных возможностей, в качестве foreach и др. Почему бы также не использовать его в качестве замены while?
-
Раньше мы уже обсуждали придание конструкциям с for значительно расширенных возможностей, в качестве foreach и др. Почему бы также не использовать его в качестве замены while?
....вы самого главного не уяснили... - для того,что бы от них была польза НЕОБХОДИМО в ЯП (на уровне яп) иметь структуры, контейнеры - а с тем что есть в Обероне вполне можно работать и с помощью существующих конструкций... - особых преимуществ расширизмы на них не дают..
-
...вы просто не уяснили...;) для массивов наличие того же foreach еще как оправдано.
-
...вы просто не уяснили...;) для массивов наличие того же foreach еще как оправдано.
только в том случае ЕСЛИ АЛГОРИТМ РЕШЕНИЯ КОНКРЕТНОЙ ЗАДАЧИ НЕ ЗАВИСИТ ОТ ПОРЯДКА ПРОСМОТРА ЕГО ЭЛЕМЕНТОВ.. ;) - а так.. рантаймовая проверка на выход за его пределы декларируется на уровне языка...
-
DIzer, в Обероне for как в Паскале.
9.8. For statements
A for statement specifies the repeated execution of a statement sequence for a given number of times, while a progression of values is assigned to an integer variable called the control variable of the for statement.
ForStatement =
FOR ident ":=" expression TO expression [BY ConstExpression] DO
StatementSequence END .
The for statement
FOR v := beg TO end BY inc DO S END
is, if inc > 0, equivalent to
v := beg; lim := end;
WHILE v <= lim DO S; v := v + inc END
and if inc < 0 it is equivalent to
v := beg; lim := end;
WHILE v >= lim DO S; v := v + inc END
Как видите, результаты выражений запоминаются во временных переменных или регистрах.
-
DIzer, в Обероне for как в Паскале.
9.8. For statements
A for statement specifies the repeated execution of a statement sequence for a given number of times, while a progression of values is assigned to an integer variable called the control variable of the for statement.
ForStatement =
FOR ident ":=" expression TO expression [BY ConstExpression] DO
StatementSequence END .
The for statement
FOR v := beg TO end BY inc DO S END
is, if inc > 0, equivalent to
v := beg; lim := end;
WHILE v <= lim DO S; v := v + inc END
and if inc < 0 it is equivalent to
v := beg; lim := end;
WHILE v >= lim DO S; v := v + inc END
Как видите, результаты выражений запоминаются во временных переменных или регистрах.
какой Паскаль ? вы сейчас говорите про реализацию.. а они могут быть различными.
-
...вы просто не уяснили...;) для массивов наличие того же foreach еще как оправдано.
только в том случае ЕСЛИ АЛГОРИТМ РЕШЕНИЯ КОНКРЕТНОЙ ЗАДАЧИ НЕ ЗАВИСИТ ОТ ПОРЯДКА ПРОСМОТРА ЕГО ЭЛЕМЕНТОВ.. ;) - а так.. рантаймовая проверка на выход за его пределы декларируется на уровне языка...
Не декларируется.
-
вы сейчас говорите про реализацию
Это цитата из сообщения о языке Оберон-7. Там ясно поясняется в псевдокоде, что сперва выражение присваивается временной переменной.
-
...вы просто не уяснили...;) для массивов наличие того же foreach еще как оправдано.
только в том случае ЕСЛИ АЛГОРИТМ РЕШЕНИЯ КОНКРЕТНОЙ ЗАДАЧИ НЕ ЗАВИСИТ ОТ ПОРЯДКА ПРОСМОТРА ЕГО ЭЛЕМЕНТОВ.. ;) - а так.. рантаймовая проверка на выход за его пределы декларируется на уровне языка...
Не декларируется.
ге ге, уже нет? :D - а я вот припоминаю строчки о невозможности ее отключения
-
вы сейчас говорите про реализацию
Это цитата из сообщения о языке Оберон-7. Там ясно поясняется в псевдокоде, что сперва выражение присваивается временной переменной.
тык и я ровно про это - что в Оберон-7 этот момент ЖЕСТКО прописан (реализация ОГРАНИЧЕНА)... к радости компиляторостроителей и Алексея (которому нравится ковыряться в дерьме).. и к моему неудовольствию - как пользователя.
-
В Активном Обероне происходят постоянные изменения. Постепенный переход как-бы не стильно отпугивает труоберонщиков, и в тоже время делает язык все более приближенным к реалиям осеписания.
Вот последние изменения из логов svn:
Major modification for declarations of system procedures / type:
SYSTEM.ADDRESS --> ADDRESS
SYSTEM.SIZE --> SIZE
SYSTEM.ADR --> ADDRESSOF
SYSTEM.SIZEOF --> SIZEOF
SYSTEM.LSH --> LSH
SYSTEM.ROT --> ROT
[SYSTEM.INCR --> INCR: Math Oberon related]
...
Added unary operators (Factors) "ADDRES OF" and "SIZE OF"
...
Added unary operator (Factor) ALIAS OF (MathOberon context). Removed ZEROCOPY.
Semantics: Assignment a := ALIAS OF b zero-copies b to a
Ну и ADDRESS вроде как становится настоящим беззнаковым целым а не алиасом для LONGINT/HUGEINT
-
В Активном Обероне происходят постоянные изменения.
линк можно, плз
-
Еще по поводу замены while.
Можно дополнить вариантом выноса за скобки счетчика: for...by...do...end;
-
линк можно, плз
Так svn, по непонятным причинам доступа простым смертним туда нет, нужно писать слезное письмо с просьбой, но сейчас и емейл не работает.
-
линк можно, плз
Так svn, по непонятным причинам доступа простым смертним туда нет, нужно писать слезное письмо с просьбой, но сейчас и емейл не работает.
Хорошо, что есть развитие, а то тут писали про кончину А2 :)
Хотел у вас спросить, реально ли на основе компилятора Сириуса, без серьезных затрат ресурсов, сделать компилятор Мод Оберона?
-
Хотел у вас спросить, реально ли на основе компилятора Сириуса, без серьезных затрат ресурсов, сделать компилятор Мод Оберона?
Напиши свой компилятор (на любимом ЯП) и реализуй любые расширизмы. Это и будет "без серьезных затрат ресурсов". Да, и с бакендом всегда можно схалявить - начиная от некой виртуальной машины (как в виртовском учебнике) и заканчивая кодом существующего ЯП.
-
http://wiki.freepascal.org/Modernised_Pascal ;)
-
Хорошо, что есть развитие, а то тут писали про кончину А2 :)
Кончина это вряд-ли - слишком хороша для исследовательских работ. Но то, что происходят скорее вялотекущие процессы, чем бурное развитие - это факт. Но за последний год проведена довольно существенная работа по увеличению стабильности и производительности, изменения для более корректной работы тачскрина, продолжается работа над новым компилятором Активного Оберона (именно этот компилятором используется сейчас для сборки А2 - i386/AMD64), соответственно и язык меняется. Т.е. работы ведутся, но явно не ударными темпами, может быть это связано с тем, что сейчас они разрабатывают новую Ось и на А2 времени не остается.
Хотел у вас спросить, реально ли на основе компилятора Сириуса, без серьезных затрат ресурсов, сделать компилятор Мод Оберона?
Сложно сказать, это всё-таки не Оберон, в Сириусе много заимствований из Модулы-3 (в основном объекты) и Delphi (rtti).
Проще, наверное, будут взять Pow! или OOC и довести до ума.
-
Вот, нашел сегодня, вроде близко к теме:
В идеале хотелось бы иметь такой язык программирования:
* простой синтаксис в стиле BASIC/Fortran
* структурное программирование
* объектно-ориентированное программирование
* обработка исключений
* оператор with как в Паскале
* функциональное программирование на уровне делегатов C# (функциональный тип, анонимные функции, замыкания)
* модульность, пакеты как в Java
* небольшой код, высокое быстродействие, как в C/C++
* кроссплатформенность на уровне компиляции
* нативный код, с возможностью низкоуровневого программирования (как в C/C++ и Паскаль)
* ручное управление памятью либо автоматическая сборка мусора, на выбор
* еще бы неплохо встроенную параллельность. Чтобы простым оператором любую функцию/метод можно было вызвать в с параметрами в отдельном треде. Например, spawn myfunc(arg1, arg2, argN)
-
фантастика
-
Что можно было бы добавить для параллельного вычисления? Взять из АО, Erlang, Go, делегаты?
-
Что можно было бы добавить для параллельного вычисления? Взять из АО, Erlang, Go, делегаты?
В Go и Erlang нет делегатов.
А также в Go его эти goroutine (горутины) не работают параллеьно - у них кооперативная многозадачность. Они сделаны не для parallel computation, а для concurrency.
-
Тоесть одновременность можно рассматривать как частный случай параллелизма?
Что должно быть в мод. Обероне?
-
фантастика
А, что мешает в этой теме обсудить "идеальный язык" и создать свою спецификацию языка, где всё будет.
Вот, нашел сегодня, вроде близко к теме:
В идеале хотелось бы иметь такой язык программирования:
* простой синтаксис в стиле BASIC/Fortran
* структурное программирование
* объектно-ориентированное программирование
* обработка исключений
* оператор with как в Паскале
* функциональное программирование на уровне делегатов C# (функциональный тип, анонимные функции, замыкания)
* модульность, пакеты как в Java
* небольшой код, высокое быстродействие, как в C/C++
* кроссплатформенность на уровне компиляции
* нативный код, с возможностью низкоуровневого программирования (как в C/C++ и Паскаль)
* ручное управление памятью либо автоматическая сборка мусора, на выбор
* еще бы неплохо встроенную параллельность. Чтобы простым оператором любую функцию/метод можно было вызвать в с параметрами в отдельном треде. Например, spawn myfunc(arg1, arg2, argN)
Можно пройтись по всем пунктам и обсудить.
Тема то, сама по себе интересная.
-
Тоесть одновременность можно рассматривать как частный случай параллелизма?
Что должно быть в мод. Обероне?
Это 1) не одновременность, 2) в частном случае является параллелизмом.
-
Тоесть одновременность можно рассматривать как частный случай параллелизма?
Параллельные задачи выполняются одновременно -- на разных процессорах/ядрах.
Конкурентные задачи выполняются попеременно -- на одном процессоре/ядре.
Монопольные задачи, понятное дело, полностью захватывают процессор/ядро и не дают другим задачам выполняться.
-
На уровне яп, думаю, достаточно уровня concurrency, а как оно будет в реальности распараллеливаться на железе, пусть решает ос.
-
На уровне яп, думаю, достаточно уровня concurrency, а как оно будет в реальности распараллеливаться на железе, пусть решает ос.
Да нет же, это разные задачи. А нужна ли поддержка всего этого на уровне ЯП - зависит от самого ЯП. В некоторых ЯП оная поддержка в общем то и не нужна особо, ибо можно сделать либой. То есть зависит от того, насколько ЯП высокоуровнев.
-
Вот, нашел сегодня, вроде близко к теме:
В идеале хотелось бы иметь такой язык программирования:
* простой синтаксис в стиле BASIC/Fortran
* структурное программирование
* объектно-ориентированное программирование
* обработка исключений
* оператор with как в Паскале
* функциональное программирование на уровне делегатов C# (функциональный тип, анонимные функции, замыкания)
* модульность, пакеты как в Java
* небольшой код, высокое быстродействие, как в C/C++
* кроссплатформенность на уровне компиляции
* нативный код, с возможностью низкоуровневого программирования (как в C/C++ и Паскаль)
* ручное управление памятью либо автоматическая сборка мусора, на выбор
* еще бы неплохо встроенную параллельность. Чтобы простым оператором любую функцию/метод можно было вызвать в с параметрами в отдельном треде. Например, spawn myfunc(arg1, arg2, argN)
Почти JAM... :)))
-
Да нет же, это разные задачи. А нужна ли поддержка всего этого на уровне ЯП - зависит от самого ЯП.
grid вычисления на уровне языка, понятно, не нужны. Параллельность нужна на уровне АО, Go.