Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 29 мар 2024, 17:21

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 30 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: 27 дек 2013, 18:06 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
Zorko писал(а):
А else куда же?


Не понял.

IF (A > B)
result := A;
ELSE
result := B;
END;

И ещё данное правило освободит от написания ;

IF (A > B)
result := A
ELSE
result := B
END

Со скобочками таже проблема, что и с паскаль begin end

if {} else if {} else {]
if then begin end else if then begin end else begin end

IF THEN ELSIF THEN ELSE END

Вариант оберона лучше.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 дек 2013, 18:15 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
Я сам не понимаю, эту замороченность со скобками и лишними begin end

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

if
elif
else
end

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 дек 2013, 18:18 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Да какая там привычка, уверен, что не только. Просто наличие отдельного слова ELSE говорит "здесь начинается наша реакция на неисполнение условия", и ещё никто не придумал сокращать его до скобочек, тогда как THEN отделяет условие от реакции на него. Это как бы маленький "BEGIN", который начинает реакцию. Переход на новую строку вместо него воспринимается как-то сиротливо.

Впрочем, у любой нотации есть свои достоинства и недостатки. В Си достоинство краткость, и я его не оспариваю. Паскаль меня всегда радовал понятностью листингов, и, возможно, одна из причин, по которой это достигается, это явное THEN. Я проговариваю в уме "то" и "иначе" когда читаю программу. И при слове "иначе" взгляд упирается в ELSE, а при слове "то" он ищет THEN, а ведь нету! ;)

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 дек 2013, 19:36 
Не в сети

Сообщения: 203
Zorko писал(а):
На самом деле "<>" хорошо обозначает "меньше или больше", но приводить "меньше или больше" в уме в "не равно" всё-таки приходится, так мы обучены думать. К тому же неравенство не обязательно обозначает "меньше или больше", например, в случае сравнения логической (BOOLEAN) или символьной (CHAR) информации ...
Согласен, операции проверки упорядоченности (больше/меньше) вовсе не обязаны быть определены для значений, которые можно сравнивать на равенство.
В том же Хаскелле (ну а о чём ещё я могу упоминать :) ) эти операции разнесены по разным классам типов -- равенство/неравенство в классе Eq, а больше/меньше -- в классе Ord:
Изображение

Zorko писал(а):
Может показаться, что мы спорим о пустяках и на пустом месте. Ну что там, дескать, скобочка такая или скобочка этакая, но нет, неудачная нотация может очень серьёзно затруднить восприятие программы "с листа". Оберон в этом смысле прекрасно уточнён.
Вот не могу я понять, как можно считать громоздкий, кричащий синтаксис Оберона/Модулы-2 утончённым, да ещё и прекрасно... о_О
Если уж искать утончённость синтаксиса, то в первую очередь надо смотреть на Хаскелл. Хотя и в Хаскелле бывает муоср, но в целом его там меньше, чем в сях, паскалях, оберонах...

Zorko писал(а):
... зачем употреблять скобки при вызове функций без параметров? Уже по способу применения можно отличить функцию от переменной во всех случаях, кроме когда функция без параметров возвращает результат. Вот здесь и только здесь в Обероне пишутся скобки:
Код: "OBERON"
  1. a := var; (* переменная *)
  2. a := func(); (* функция *)
А как ещё отличить вызов функции от использования ссылки на функцию?
Код: "OBERON"
  1.  
  2. TYPE FooProc = PROCEDURE (): INTEGER;
  3.  
  4. VAR
  5. x, y, z: INTEGER;
  6. f: FooProc;
  7.  
  8. PROCEDURE Foo(): INTEGER;
  9. BEGIN
  10. RETURN 42
  11. END Foo;
  12.  
  13. ...
  14.  
  15. x := 1;
  16. y := x; (* присваиваем значение переменной x *)
  17. f := Foo; (* присваиваем ссылку на функцию Foo *)
  18. z := Foo(); (* присваиваем значение функции Foo *)
Или я не так понял твою мысль?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 дек 2013, 19:38 
Не в сети
Администратор
Аватара пользователя

Сообщения: 273
Откуда: Россия
Zorko писал(а):
"#" имеет преимущество перед "/=" в том, что перечёркивание равности параллельных прямых хоть и двойное, но всё-таки обозначено, а в "/=" его приходится "додумывать", сдвигая "/" вправо ровно на "=". Так что дядька Вирт опять не прогадал. Остаётся только удивиться, почему же символ "#" не использовали для обозначения неравенства раньше, в других языках до Оберона.
1)Ну это опять-таки дело вкуса: мысленно передвигать черточку или в уме убирать лишнюю палочку. Но в целом, да, знак выбран удачно.
2)Символ # в качестве знака "не равно" использовался в Foxpro (наряду с "<>").
Zorko писал(а):
Взять лишние скобки в программах на Си-подобных языках. Чем реально оправдать их наличие в if(), for(), switch(), while(), кроме как упрощением парсера?
Сэкономили на ключевых словах (then, of, do), но пришлось чем-то отделить условие от операторов. Если сравнивать текстуально, то вместо Паскалевского "if" в Си используется "if(", а вместо "then" - закрывающая скобка ")".
Чем это плохо? В условиях очень часто встречаются скобки, а вот "then" может встретиться в условии разве что внутри строковой константы. Чем отличается )"скобка-then" от всех прочих скобок? Только уровнем вложенности - какая это скобка по-порядку. Что будет, если вы скобки в условии перепутаете (довольно обычная ошибка)? В Обероне или Паскале then четко говорит, что условие кончилось: если баланс скобок не соблюден, то можно зафиксировать ошибку в условии и разбирать последующие операторы. В Си при ошибке в условии компилятор может перепутать условие с последующим оператором "++x=...", что вызовет дальнейшую путаницу. Конечно, какое-то сообщение об ошибке появится, но будет непросто понять, что ошибка на самом деле в условии.
Конечно, хорошо, когда ключевых слов немного — и компилятор проще и программисту их легче запомнить и больше осмысленных слов остается для своих идентификаторов. Но при недостатке ключевых слов приходится либо применять «закорючки», либо использовать одно и то же слово в разных смыслах. Ключевые слова более наглядны просто потому, что занимают больше места на экране\бумаге и человеку легче их распознать - взгляду есть за что зацепиться, «рожек и ножек» у нескольких символов суммарно больше, чем у одного. Да и набирая символ на клавиатуре трудно ошибиться так, чтобы из одного ключевого слова получилось другое (если они правильно подобраны): ключевые слова разнесены дальше друг от друга (в смысле расстояния Хэмминга), чем отдельные символы.
Если каждое ключевое слово имеет свой собственный фиксированный смысл, то компилятор уже по самому слову понимает, что это значит и может зафиксировать ошибку, если слово стоит не там, где должно. Если же смысл слова зависит от его положения, то существует опасность путаницы, когда положение из-за чего-то сдвинется (см. выше про «скобку-then»).
Конечно на каждый смысл слов не напасешься, но тогда надо применять совпадающие слова так, чтобы при сдвиге они не смогли перепутаться. Вот, например, в КП слово IN может означать и отношение «принадлежит» и «параметр для ввода», но перепутаться они не могут, потому что используются совсем в разных местах.
Это еще один объективный критерий оценки ЯП (наряду с «арифметикой синтаксиса» Свердлова): насколько далеко разнесены комбинации символов, признаваемые компилятором верными; легко ли получить из одной синтаксически верной конструкции другую синтаксически верную. :idea:
И вот в этом отношении языки Вирта тщательно продуманы: опечатка приведет скорее всего к ошибке компиляции, а не к другой синтаксически допустимой конструкции. «Островки правильных конструкций» разнесены далеко друг от друга в «море ошибок». И если случайно оступиться, то попадешь не на другой островок, а в воду. Это сразу же будет заметно — ошибка компиляции. Чтобы попасть на другой остров, нужно затратить определенные сознательные усилия, что уже не может быть случайным.
Разумеется, если вы при вычисления площади прямоугольника напишите «+» вместо «*», то получите неверный результат. И никакой синтаксис и строгая типизация тут не помогут, ведь никакой компилятор не может знать, что вы хотели получить площадь, а не полупериметр. :(
Но всё возможное, что можно сделать синтаксисом, в виртовских языках делается! :!:
В отличие от Си-образных, где не «островки в море», а скорее беспорядочная груда. Протянув руку за одним вы вполне можете схватить совсем другое, стоит руке чуть дрогнуть. :evil: И никто вас не предупредит, компилятор вам не поможет, он сам едва-едва в этой свалке разбирается. Вот оно обилие возможностей, вот она свобода — свобода совершать обильные ошибки!
Уж о чем думали создатели Си, но только не об ошибкоустойчивом синтаксисе. "Си-язык для профессионалов, а профессионалы не ошибаются!" ;)
Цитата:
Ну да это уже ладно, но зачем употреблять скобки при вызове функций без параметров? Уже по способу применения можно отличить функцию от переменной во всех случаях, кроме когда функция без параметров возвращает результат. Вот здесь и только здесь в Обероне пишутся скобки: ...
В Обероне легко отличить, а в С синтаксис очень замысловатый и подсказка "это функция" может потребоваться во многих случаях. Описать когда она нужна, когда нет, довольно сложно, проще задать "() нужны всегда!".


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 дек 2013, 19:42 
Не в сети

Сообщения: 203
Jordan писал(а):
И ещё данное правило освободит от написания ;
Код: "OBERON"
  1. IF (A > B)
  2. result := A
  3. ELSE
  4. result := B
  5. END

Если уж развивать такую идею, то надо идти дальше:
Код: "OBERON"
  1. statement_1
  2.  
  3. IF A > B
  4. statement_then_1
  5. statement_then_2
  6. ELSE
  7. statement_else_1
  8. statement_else_2
  9.  
  10. statement_2


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 дек 2013, 20:14 
Не в сети

Сообщения: 203
Saferoll писал(а):
Разумеется, если вы при вычисления площади прямоугольника напишите «+» вместо «*», то получите неверный результат. И никакой синтаксис и строгая типизация тут не помогут, ведь никакой компилятор не может знать, что вы хотели получить площадь, а не полупериметр.

Вообще-то, строгая типизация в данном случае как раз может помочь, но для этого надо иметь более продвинутую ситсему типов, чем в оберонах или сях -- типы с единицами измерений. Таковые есть из коробки в языке F#, могут быть библиотечно добавлены в С++...
Вот пример на F#:
Код: "OBERON"
  1. [<Measure>] type m
  2. [<Measure>] type m2 = m^2
  3.  
  4. let square (x: float<m>) (y: float<m>) : float<m2> =
  5. x * y
  6.  
  7. let perimeter (x: float<m>) (y: float<m>) : float<m> =
  8. 2.0 * (x + y)
  9.  
  10. [<EntryPoint>]
  11. let main argv =
  12. printfn "%f" (float(square 3.0<m> 4.0<m>))
  13. printfn "%f" (float(perimeter 3.0<m> 4.0<m>))
  14.  
  15. 0 // return an integer exit code
Тут всё правильно, а вот тут:
Код: "OBERON"
  1. [<Measure>] type m
  2. [<Measure>] type m2 = m^2
  3.  
  4. let foo (x: float<m>) (y: float<m>) : float<m2> =
  5. x + y
ошибка компиляции на переменной y:
Error 1 The unit of measure 'm2' does not match the unit of measure 'm'

Для Хаскелла также есть библиотеки dimensional и dimensional-tf, но я пока в них не ковырялся, вот пример, если кому интересно:
https://code.google.com/p/dimensional/wiki/ErrorMessagesAndDebugging
Код: "OBERON"
  1. > import Numeric.Units.Dimensional.Prelude
  2. > import Numeric.NumType (Zero, Pos3, Neg2)
  3. > import qualified Prelude
  4.  
  5. The angular velocity of Earth's rotation (Soop p. 7).
  6.  
  7. > phi :: AngularVelocity Double
  8. > phi = 360.985647 *~ (degree / day)
  9.  
  10. The gravitational parameter of Earth.
  11.  
  12. > mu :: Quantity (Dim Pos3 Zero Neg2 Zero Zero Zero Zero) Double
  13. > mu = 3.986004400008003e14 *~ (meter ^ pos3 / second ^ pos2)
  14.  
  15. The ideal geostationary radius and velocity.
  16.  
  17. > r_GEO :: Length Double
  18. > r_GEO = cbrt (mu / phi ^ pos2)
  19. > v_GEO :: Velocity Double
  20. > v_GEO = phi * r_GEO
  21.  
  22. Something obviously wrong.
  23.  
  24. > dont_try_this_at_home :: Velocity Double
  25. > dont_try_this_at_home = v_GEO + mu


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 28 дек 2013, 08:43 
Не в сети

Сообщения: 13
geniepro писал(а):
Saferoll писал(а):
Разумеется, если вы при вычисления площади прямоугольника напишите «+» вместо «*», то получите неверный результат. И никакой синтаксис и строгая типизация тут не помогут, ведь никакой компилятор не может знать, что вы хотели получить площадь, а не полупериметр.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 28 дек 2013, 14:40 
Не в сети

Сообщения: 203
igor писал(а):
geniepro писал(а):
Saferoll писал(а):
Разумеется, если вы при вычисления площади прямоугольника напишите «+» вместо «*», то получите неверный результат. И никакой синтаксис и строгая типизация тут не помогут, ведь никакой компилятор не может знать, что вы хотели получить площадь, а не полупериметр.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 28 дек 2013, 16:26 
Не в сети

Сообщения: 13
geniepro писал(а):
А вот если по задаче нужны такие дополнительные ограничения, ...
... , то лучше их решать на уровне задачи, а не на уровне языка. ИМХО.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 30 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club