Oberon space

Код: [Выделить]

qsort=: (($:@(<#[) ; (=#[) ,&< $:@(>#[)) ({~ ?@#)) ^: (1<#)


Полный привет. Можно пугать оберонщиков, когда они в очередной раз будут крутить нос от сишного синтаксиса

Цитата: vlad от Март 14, 2011, 05:03:07 pm

А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.

А должна была бы округлить координату 0.5 до целого и нарисовать одну плотную линию в нужном месте с точностью до межпиксельного расстояния. А вот с наклонными линиями тактика всё-же должна быть наверно другой.

Не может она сама округлить. Потому что ожидается, что линии 0.5000001 и 0.4999999 должны быть визуально неотличимы. Так же как 0.9999999 и 1.0000001.

P.S. Да, с наклонными вообще песня...

Примерно из той же оперы. Есть такой фрэймворк на маке (вроде и не только) - quartz. Грубо говоря, чтоб рисовать где только можно и как только можно. Там все круто - забудьте о пикселах, вот вам вещественные координаты, антиалиасинг и т.д. Классно. Только при ближайшем рассмотрении оказывается, что для того, чтобы нарисованное выглядело прилично на мониторе - нужно знать, что такое пиксел и формировать координаты соответственно. Например, горизонтальна линия с координатами (0,0) - (100,0) и толщиной 1 - выглядит неприемлимо. А вот с координатами (0,0.5) - (100,0.5) - нормально. А вот линия с толщиной 2 - наоборот. Приличное рисование геометрических примитивов в таком фрэймворке - страшный гемор и требует "особенного" подхода к округлению и преобразованиям между целыми и вещественными. В компилятор такую фигню не засунуть в принципе.

Кроме того, что я просто не хочу запрещать сравнение вещ. чисел на равенство, я ещё и не представляю как это сделать безболезненно. Ведь вместо банальных x и y  в общем случае могут быть сложные выражения (либо x и y вычисляются перед использованием в логическом выражении), тип результата которых станет известен только на этапе выполнения программы. И что должна делать программа, если этот тип окажется вещественным? Аварийное завершение?

Гхм. Если речь идет о статически-типизированном языке (а-ля оберон), то тип всех выражений известен на этапе компиляции. Независимо от сложности. Так что "оказаться вещественным" он может только на этапе компиляции.

Но как можно запретить сравнивать вещественные числа? Ведь необходимость в этом обычно исходит из самой задачи.

Ну в смысле как? Как обычно: (x + погрешность) > y > (x - погрешность). Причем погрешность выбирается "из самой задачи".

Что должно произойти при выходе индекса за пределы массива  - можно посмотреть в исходном коде модуля обеспечения времени исполнения, Kernel (для КП):

Вы там увидите только то, в чем именно заключается неописанный в языке undefuned behavior. Все описанные проблемы (vendor lock, переносимость) - остаются в силе. Да, эти проблемы могут быть неактуальными для вас (или казаться неактуальными).

[quote author=vlad link=topic=26
В экосистеме КП/ББ не принято иметь несколько версий одного модуля. Т.е. традиционная для модульных языков вариантивность на уровне "1 спецификация модуля - несколько реализаций" (вполне неплохая по-своему) ушла в прошлое, уступив место объектно-ориентированным разъёмам, когда  функцию интерфейса выполняет один модуль, и в нём же объявлен тип разъёма, а функцию реализации выполняют другие модули, с различными именами, динамически загружаемые и втыкающие свои разъёмы. Это более сильный и общий подход - динамическое подключение реализаций, много реализаций одновременно, не нужна перекомпиляция и т.п. Т.е. как бы мета-подход, который снимает с уровня самих модулей некоторую старую смысловую нагрузку. Отсюда же утрата прежнего значения отдельной спецификации модуля.

Не, не улавливаю. Чем это принципиально отличается от классических ООП интерфейсов? Сколько угодно модулей могут реализовать заданный интерфейс и т.д. по списку.

6. Модуль = процесс, процедура модуля - тред.

Это как?