Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  01:25[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 3736—3727 | 3726—3717 | 3716—3707 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 254


№ 3726   07-04-2007 13:31 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3724« (Jack Of Shadows)
___________________________

Код пишется не для компилятора а для человека.

Во-первых, не код (code), а исходный текст (source). Я понимаю желание американцев все упрощать до неузнавания. Но не надо за ними вторить глупости. Отсюда, кстати, и пошло пренебрежительное "кодер" по отношению к программистам. Исторически код -- это объектный или машинный код (понимается исключительно программой/машиной). А исходный текст -- он и для человека, и для машины (программы). В этом терминологическая разница.

Во-вторых, исходный текст подразумевает два разных режима обработки (что для человека, что для машины): синтез и анализ. Синтезирует обычно человек (хотя может и машина). Анализируют оба.

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

Анализ человеком делится на два вида: без отчуждения ("писатель = читатель") и с отчуждением ("писатель # читатель"). При отчуждении основное принципиальное требование -- возможность разрешения всех коллизий сторонним читателем на основе только исходных текстов на данном языке (включая интерфейсы) без использования умолчаний среды, конфигурации IDE, запросов к писателю и т.п. Если такие коллизии могут быть всегда разрешены, проблема неоднозначностей снимается. Остальное -- дело вкуса (а не технологической дисциплины).

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


№ 3725   07-04-2007 13:10 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3723« (Руслан Богатырев)
___________________________
Слова ради слов. Императивный язык на то и императивен.
В смысле на то и императивен чтобы ставить подножки в коде в виде неявного и неочевидного из кода изменения состояния переменных ?
(Надеюсь что с этим вопросом я упаду в ваших глазах еще ниже)


№ 3724   07-04-2007 13:07 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3722« (Руслан Богатырев)
___________________________
а при фактических "квалификация" передачи не делается (она однозначна для компилятора и не требует его домысливания).
Код пишется не для компилятора а для человека.
Глядя на такую функцию человек понятия не имеет что одна из переменных может после передачи ее в функцию вдруг  поменять значение.
Вот где код трудно понять "с листа".


№ 3723   07-04-2007 13:05 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3721« (Jack Of Shadows)
___________________________

Вот тут надо было быть последовательным и принципиальным до конца.

Джек, чем дальше, тем Вы все ниже падаете в моих глазах. Слова ради слов. Императивный язык на то и императивен. Это другое дерево. Не ФП.


№ 3722   07-04-2007 12:57 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3719« (Антон Григорьев)
___________________________

Тем не менее, в Обероне перед фактическим параметром-переменной VAR ставить не нужно. Это недостаток Оберона, или между этими ситуациями всё же есть принципиальная разница, которую я пока не вижу?

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

В классическом Обероне для формальных параметров используется схема Модулы-2 (VAR для передачи по ссылке, ничего -- для передачи по значению). Для передачи по имени (как в Алголе) используются процедурные переменные. В том же классическом Паскаля (1970) была более навороченная схема: перед именем формального параметра указывался конкретно вид сущности -- const, var, function, procedure.

В Компонентном Паскале взяли схему, близкую к Аде: VAR, IN и OUT. Т.е. для передачи по значению не указывается ничего (режим всегда in), а при передачи по ссылке "квалифицируется" характер передачи -- in, out или inout. Но это все относится к формальным параметрам, а при фактических "квалификация" передачи не делается (она однозначна для компилятора и не требует его домысливания).


№ 3721   07-04-2007 12:49 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3719« (Антон Григорьев)
___________________________
Это недостаток Оберона, или между этими ситуациями всё же есть принципиальная разница, которую я пока не вижу?
Огромная разница. И это большой недостаток оберона.
Обьясняю. Функция возвращает данные ТОЛЬКО одним единственным способом, через возвращаемый параметр.
То есть это то что программист от нее ОЖИДАЕТ.
Поэтому когда функция вдруг меняет один из передаваемых ей параметров - это удар в спину ничего не подозревающему программисту. Все точки в которых данные МОГУТ быть изменены должны быть ЯВНО помечены.
Иначе вас ждут неприятные сюрпризы. Вот тут надо было быть последовательным и принципиальным до конца.


№ 3720   07-04-2007 12:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3716« (Jack Of Shadows)
___________________________

А вот в Эрланге - ради бога можно и file.open :))

Все объясняется разной школой. Те, кто создавал Erlang, были сторонниками школы Вирта и Дейкстры. Всего лишь.

Ноги Erlang растут из EriPascal -- он вышел из экспериментов над средой PLEX (Programming Language for EXchange Switches) в компании Ericsson. Создавался как альтернатива языку CHILL (CCITT High Level Language).

Автор языка Бьерн Декер (Bjarne Dacker) писал, что идеи Erland и EriPascal вышли из виртовских языков: Паскаля, Модулы-2 и PL360. Да и личность самого Вирта сыграла здесь не последнюю роль. On my wall I have a framed photograph of myself presenting PASTEL for Niklaus Wirth. That was some experimental language that we were working on at the same time as he was working on Modula. I actually listened to his first lecture presenting Modula for his students in Zurich in hoch deutsch! Instead of PASTEL there came EriPascal but just imagine how beautiful manuals we could have printed!
http://www.erlang.org/pipermail/erlang-questions/2003-February/007354.html

Еще из его воспоминаний: I went to a Pascal conference in Southampton in 1977 and Brinch-Hansen described Concurrent Pascal. When asked what he thought of Modula (that Wirth just had brought out), he replied that you might do something clever but then "Claus" would come with the worked-through elegant version of it!

По мнению же Джо Армстронга, другим источником идей были работы Дейкстры: One other work which influenced Erlang was Dijkstra's idea of guarded commands - Dijkstra liked *every* alternative in a multi-way branch to have a guard.
http://www.erlang.org/pipermail/erlang-questions/2003-February/007325.html


№ 3719   07-04-2007 12:32 Ответить на это сообщение Ответить на это сообщение с цитированием
В силу жизненных обстоятельств пришлось начать изучение C#. И столкнулся с такой особенностью этого языка: если формальный параметр объявлен как ref (аналог var в Паскале), то и перед фактическим параметром при вызове этой функции необходимо ставить ключевое слово ref. Что-то вроде такого:

void SomeFunc(ref int Param);
....

// Вызов
int i;
SomeFunc(ref i);



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


№ 3718   07-04-2007 12:29 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3717« (Trurl)
___________________________
Сообщением "Unresolved overloading" ;-)

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


№ 3717   07-04-2007 12:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3711« (Geniepro)
___________________________
>>>H: Чушь. Автоматический вывод типов нам поможет! :о))
Сообщением "Unresolved overloading" ;-)


<<<... | 3736—3727 | 3726—3717 | 3716—3707 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 254


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

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

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования