[11:33:29] <valexеy> Хабр, обсуждение топика "Что будет после вступления в силу закона «О защите детей от информации?»"

GearHead: меня очень забавляет формулировка: «информация, причиняющая вред здоровью». прочитал сынок пост в блоге, и у него мозг взорвался.
Sterhel: Ага, прочитал какой-нибудь политический пост о том, как все в стране делается только для нашего благополучия, обоссался кипятком со смеху — и бегом в ожоговый центр, фиксировать повреждения.
[12:37:06] <egp> я тут название придумал для языка программирования:
SSAL - Scientifically Sound Algorithmic Language :)))
[12:37:16] <egp> (14:51:57) egp: Но лучше название PA - Portable Algorithms
(14:52:26) egp: или PASS: Portable Algorithms Scientifically Sound
[12:37:42] <egp> valexеy, я щас думаю над идеей смешать подходы смолтока и оберона
[12:38:08] <egp> то есть 1) система может базироваться на имидже как у сквик-смолтока
[12:38:23] <egp> 2) внутренний формат портабелен, НО
[12:39:10] <egp> 3) не байткод, как у явы или смолтоков, НО внутреннее представление - это портабельное AST, как у juice
[12:39:33] <valexеy> то есть грубо говоря - это тупо исходник пожатый и загнанный в бинарный вид
[12:39:37] <valexеy> скучно
[12:40:13] <egp> 4) кодогенерация из AST который лежит в имидже осуществляется в машкод текущей платформы либо кросс-компилером в машкой таргет-платформы
[12:41:04] <valexеy> а смысл? с тем же успехом можно тупо исходник компилять. к чему эти сложности?
[12:41:48] <egp> valexеy, исходники могут распространяться так же как это принято в смолтоке - там рабочая система всегда состоит из 4 компоненет - А имидж-файл Б вмка (экзешник и его ресурсные файлы и дллки) В плуги к вмке (ДЛЛки и их ресурсные файлы и под-дллки) Г сырец-файл к имиджу
[12:42:19] <egp> valexеy, это ушустряет работу с исходником и компилером
[12:42:21] <valexеy> еще раз - нафига промежуточное представление бинарное (бинарный AST), если можно обойтись без него?
[12:42:34] <valexеy> у компилятора оберона нет проблем с быстродействием
[12:42:43] <valexеy> то есть вообще.
[12:43:01] <egp> неправда. у оптимизирующих компилеров большущие проблемы с быстродействием
[12:43:08] <valexеy> даже у компилятора жабы нет таких проблем :-) равно как и у котлина например
[12:43:25] <valexеy> не замечал проблем с быстродействием у компиляторов.
[12:43:44] <egp> у неоптимизирующих, если брать АСТ как инпут, обработка будет значительно шустрее, потому как не будет такого времязатратного механизма, как сканер лексеровский
[12:44:08] <egp> valexеy, погоняй глобальный оптимизер XDS - заметишь что он небыстр
[12:44:20] <valexеy> кроме того, ты тут экономишь лишь фазу перевода из текстового файла в ast, а на этом этапе особых оптимизаций не делается. то есть оптимизирующему компилятору это не поможет
[12:44:54] <valexеy> у xds, как и у многих компиляторов в elf/pe основной тормоз это не компиляция, а компоновка.
[12:44:55] <egp> оптимизирующему поможет за счет того что найденные оптимизации можно кешировать в имидж-файле это раз
[12:45:14] <egp> у XDS посткомпоновочный оптимизатор есть
[12:45:23] <valexеy> не поможет. оптимизации машинно зависимые.
[12:45:25] <egp> оптимизит систему в целом
[12:45:34] <egp> оптимизации не все машиннозависимы
[12:45:44] <valexеy> но это не компилятор делает.
[12:45:49] <egp> кроме того можно добавить непортабельные кеши оптимизатора
[12:46:08] <egp> это делает не компилятор, а часть компилятора - постлинк-оптимизер
[12:46:35] <valexеy> кроме того, для того, чтобы действительно иметь оптимизирующую компиляцию, нужна ПОЛНОТЕКСТОВАЯ компияция, то есть говорим прощай независимой компиляции модулей. компилируем ВСЮ систему целиком как монолит. вот тогда будет работать быстро.
[12:46:40] <egp> ну вот фаза перевода из тхт в аст довольно ресурсоемка по времени
[12:47:03] <egp> далеко не прощай
[12:47:09] <valexеy> и вот тогда и вылезают сложности со скоростью. но построение AST'a - это очень быстро в любом случае для оберона. это не та стадия на которой нужно экономить что-то кэшируя
[12:47:16] <egp> XDS не говорит прощай незав.компиляции
[12:47:37] <egp> очень быстро, а мой juice-подход ЕЩЁ быстрее
[12:48:08] <valexеy> xds не производит полнотекстовую компиляцию, насколько я помню.
[12:48:14] <egp> на всех стадиях можно экономит, в особенности на сканере txt
[12:48:56] <egp> valexеy, у XDS сто пудов есть полнотекстовый транслятор - в какие релизы он включен а в какие нет - это уже другой вопрос.
[12:49:15] <egp> я сам видел как этот полнотекстовый транслятор действует
[12:49:18] <valexеy> в реальном мире перевод из исходника оберона в ast для него не занимает времени вообще. это не стоит тех сложностей которые привносит промежуточный формат для исходников. в том числе и в организационном смысле.
[12:49:39] <egp> занимает
[12:49:42] <egp> неправда
[12:49:45] <valexеy> xds умеет хотя бы инлайнить функции из чужих модулей?
[12:49:51] <egp> хз
[12:49:57] <egp> скорее всего да
[12:50:11] <egp> но я не в курсе какие оптимизации там сделаны
[12:50:41] <valexеy> тогда ты не в курсе есть там полнотекстовая компиляция или нет :-)
[12:50:51] <egp> я в курсе что она есть
[12:50:57] <egp> но какая она в деталях я не знаю
[12:52:51] <valexеy> я не уверен что ты понимаешь смысл этих слов полностью. посмотри пожалуйста на полнотекстовый компилятор Standard ML -- MLTon. (http://en.wikipedia.org/wiki/MLton) основные тормоза при такой оптимизации не в построении AST'a. Построение AST'a из текста по времени ничтожно.
[12:53:16] <egp> valexеy, ну честно говоря полной уверенности у меня нет по части полнотекстовой трансляции у ХDS, но вроде бы оно должно быть
[12:53:52] <egp> ессно я полностью не понимаю, я этим не занимался пока
[12:54:04] <egp> но как бы надо позаниматься, засаваю линк в почту
[12:57:21] <valexеy> деревья франца эти были придуманы тогда, когда рабочие станции были слабее современного мобильника (не смартфона). сейчас эти деревья проблем никаких не решат, но, скорее всего, добавят (ибо лишняя прослойка).
[12:58:48] <egp> не факт что лишняя
[12:58:55] <egp> НО
[12:59:14] <egp> я щас прихожу к вопросам кодировки алгоритмов
[12:59:59] <egp> и подошёл к неправильности превращения естественного языка в криптосинтаксис. Примеры криптосинтаксиса: ARRAY 256 OF CHAR
[13:00:13] <egp> пример криптосинтаксиса: a := b
[13:00:33] <egp> но это уже необероновая как бы тема а общеязыковая
[13:00:50] <egp> считаю что нужен точный формальный язык на базе естественного
[13:01:35] <valexеy> зачем нам естественный язык в программировании?
[13:02:00] <egp> моя гипотеза такова что большая портабельность исходного кода может быть обеспечена
[13:02:30] <egp> на базе афоризма "LITERAL-MINDEDNESS IS GOOD."
[13:03:07] <egp> фактически это личные исследования
[13:03:08] <egp> поиск
[13:03:17] <egp> ищу то не знаю что
[13:04:24] <egp> вот мне надо приглядеться к Аде, ПЛ/1, COBOL
[13:05:12] <valexеy> haskell!
[13:05:59] <egp> я вот щас думаю о том почему у меня вообще вылезла страсть к этому имидж-подходу. Размышляю
[13:06:32] <egp> просто дело в том
[13:06:44] <egp> что в имидж можно класть не АСТ а оберон-сырцы
[13:07:24] <egp> хочется не папку с оберон-сырцами, это всё же не кроссплатформенно, а именно имидж, который наиболее кросс-платформенен
[13:09:06] <egp> то есть имеем кроссплатформенный бинарный обьект (большую бинарную строку), который хэндлится вмкой
[13:09:16] <egp> вмка уже некроссплатформенна
[13:10:22] <valexеy> иногда это оправданно, но часто это геморрой. придется вводить импорт-экспорт файлов в этот имидж. в общем, директория с файлами вполне удобна.
[13:10:38] <valexеy> либо опиши почему директория+файлы не достаточны тебе
[13:10:39] <egp> лучше не импорт-экспорт, а АПИ
[13:11:06] <egp> заметь, оберон-репорт не говорит ничего про файловые системы
[13:12:10] <valexеy> оберон репорт вообще ничего не говорит о инструменте для прикладного программиста
[13:12:22] <valexеy> тащемто ты там и hello world не напишешь
[13:12:45] <valexеy> алсо там нет механизма для освобождения памяти. там НИЧЕГО не говорится про сборщик мусора
[13:13:18] <egp> ну вот в сквик смолтоке ЧРЕЗВЫЧАЙНО удобны носимые имиджы
[13:13:41] <egp> его копи-пасте в другую ОС - и все продолжает пахать в другой ос
[13:14:03] <egp> нужно изобретать формат архива семейства оберон-модулей
[13:14:16] <egp> в котором нет ничего про файлы, а есть про модуля
[13:15:02] <valexеy> не понимаю проблемы. ну закатай в имидж диска, который потом можно подмонтировать (во всех реальных ОС есть штатные средства искаропки которые позволяют монтировать образы диска).
[13:15:45] <valexеy> короче - ты бы написал какие проблемы с файлами-диекториями есть, и каким образом некие магические имиджи их смогут решить.
[13:16:08] <valexеy> аккуратно два списочка. и отдельно - почему на уровне файлов-директори их решить не получится.
[13:16:08] <egp> вот хочется избавиться от лишних сущностей "файл", "папка", "имя пути", "имя файла"
[13:16:53] <egp> в лишних сущностях и проблема. Моя голова пуриста отказывается их принять
[13:17:58] <valexеy> покури plan 9 и inferno :-)
[13:18:11] <egp> ртосы... мат.док-ва...
[13:18:15] <egp> это не совсем то
[13:18:27] <egp> немного уже курил :)
[13:18:30] <egp> слегонца
[13:18:54] <egp> удоволился разговорами о них + статьями в википедии и на их сайтах
[13:19:27] <valexеy> э?  при чем тут реалтайм и матдоказательства? plan 9/inferno не имеет никакого отношения ни к тому ни к другому
[13:19:52] <egp> одна из версий inferno математически доказана полностью
[13:20:01] <egp> вроде это был инферно
[13:20:11] <egp> сказано о сём в википедийной странице инферно
[13:20:36] <egp> вроде бы это был инферно
[13:22:21] <egp> а что в них нет этих всех сущностей?
[13:22:49] <egp> ну собсно делать для избавления от сущностей новую ос - это чересчур
[13:23:19] <egp> для этого надо не ос, а апи
[13:23:55] <egp> например функцию GetModuleText(moduleName : ARRAY OF CHAR)
[13:24:24] <egp> или лучше GetModuleText(moduleName: ImmutableStrings.ImmutableString)
[13:24:48] <egp> и GetModuleText вертает ImmutableString
[13:25:40] <egp> и PROCEDURE SetModuleText(moduleText: ImutableString);
[13:26:14] <egp> вот эти две функции апи достаточны
[13:26:41] <egp> SetModuleText верифицирует модуль на компилябельность)
[13:27:04] <egp> ой опечатка
[13:27:28] <egp> (* вот так корректно *) PROCEDURE SetModuleText(moduleName, moduleText: ImutableString);
[13:27:32] <valexеy> а я где-то про написание ОС говорил? :-)
[13:27:45] <egp> ну план9 и инферно вроде бы осы
[13:28:03] <egp> ну у меня своих идей вал, чтобы было время ещё чужие идеи впитывать :)
[13:28:32] <egp> на досуге только если, ща у меня писательное настроение а не читательное :)
[13:29:07] <egp> сохранил диалог в почту
[13:29:25] <valexеy> инферно это примерно такая же ос, как и сквик смалтолковый :-)
[13:31:43] <egp> для максимально шустрой реализации ImmutableString мне нужен тип READONLY CHAR
[13:32:05] <egp> например ARRAY OF READONLY CHAR
[13:32:30] <egp> хотя я бы исключил keyword ARRAY из лексикона
[13:32:48] <egp> и вместо него использовал бы MAP FROM SET TO SET
[13:33:01] <valexеy> а я бы не стал зацикливаться на синтаксисе :-)
[13:33:02] <egp> где SET:= SETTYPE
[13:33:07] <egp> а я бы стал
[13:33:57] <egp> где SETTYPE:= INTERVAL_IN_N(a, b), where a, b \belongs_to
[13:34:03] <valexеy> ну, дело твоё :-)
[13:34:22] <egp> \belongs_to \ZNumbersSet
[13:35:06] <egp> SETTYPE:= INTERVAL_IN_Z(a, b)
|
[READONLY] CHAR
|
etc.
[13:37:30] <egp> и ввёл бы функции min(Dom SETTYPE) и max(Dom SETTYPE)
[13:37:43] <egp> вместо ARRAY
[13:38:13] <egp> valexеy, мне просто охота более математичный синтаксис сформировать
[13:39:13] <egp> а не
[13:39:21] <egp> не Dom SETTYPE
[13:39:32] <egp> а Dom MappingType
[13:40:00] <egp> ARRAY OF --- это типичный MAPPING_TYPE
[13:41:39] <valexеy> гм. похоже, что я не знаю что такое "более математический синтаксис"
[13:43:58] <egp> вместо := можно писать PROCEDURE (v: VARIABLE_INSTANCE).SET_VALUE(value: VARIABLE_VALUE_INSTANCE) RETURNS NOTHING;
[13:44:16] <valexеy> можно. lisp way :-)
[13:44:24] <egp> ммм...
[13:44:35] <valexеy> и haskell way :-)
[13:44:52] <valexеy> ибо своих операторов ты там можешь сколько угодно наплодить - они ведь обычные функции
[13:45:05] <egp> не обязательно функции
[13:45:24] <egp> достаточно представлений чего-либо
[13:45:39] <egp> то есть формул и термов
[13:46:20] <egp> а как эти формулы и термы будут интерпретироваться - вопрос второй
[13:46:57] <egp> то есть они собственно интерпретируются ИСЧИСЛЕНИЕМ
[13:47:17] <egp> такое в лиспе и хаскелле вряд ли реализовано
[13:47:25] <egp> можно конечно реализовать
[13:48:08] <egp> valexеy, занимался в лиспе и хаскелле кто-нить типом ИСЧИСЛЕНИЕ (англ. CALCULUS) ?
[13:48:40] <valexеy> что оно из себя предстваляет?
[13:48:59] <egp> ну математическое понятие исчисления
[13:49:48] <egp> я вот знаю одного программиста кто упоминал слово "исчисление" в своих статьях, его зовут Quinn Tyler Jackson, и им было построено так называемое "Meta-S calculus".
[13:50:07] <valexеy> а зачем оно нужно?
[13:50:21] <egp> кроме того, авторы (или автор) системы darcs использовал "Patch calculus".
[13:50:32] <egp> зачем... для большей формальности языка.
[13:50:40] <egp> т.е. для большей точности
[13:50:44] <egp> и строгости
[13:51:55] <egp> вот это Meta-S связано со специальным классом адаптивных грамматик и их транслятором в машкод/интерпретатором
[13:52:43] <egp> например, полный синтаксис C++ прекрасно реализуем в терминах грамматик Meta-S. Однако обычные парсеры C++ намного шустрее Meta-S парсера С++.
[13:53:36] <egp> НО обычные грамматики С++ всегда dirty ungrammatical hacks. А вот Meta-S грамматика С++ строга и не требует НИКАКИХ грязных хаков для реализации полного парсера С++.
[13:54:17] <egp> но она малость то ли гиперболическую сложность имеет (либо экспоненциальную по размеру С++ проги)
[13:54:31] <egp> не знаю какая у неё сложность
[13:56:11] <egp> я только графики скорости парсеров С++ видел в статьях QTJ, оценок скорости Meta-S парсера C++ в виде формул в статьях QTJ нету.
[13:56:28] <egp> ну и эти графики похожи на экспоненту
[13:56:43] <egp> может и степенная функция
[13:56:56] <egp> он просто побенчмаркал, а формулы выводить не стал
[13:56:56] <valexеy> c++ отлично парсится glr-парсером
[13:57:05] <valexеy> а glr-парсеры спокойно генерит обычный bison.
[13:57:16] <egp> ну это старые статьи у QTJ, он про glr не писал
[13:57:27] <egp> и про бизон не писал
[13:57:45] <valexеy> без грязных хаков
[13:57:54] <egp> круто, учту
[13:58:15] <egp> его статьи я читал в году 1995-2005
[13:58:46] <egp> интересно когда такие парсеры появились, про которые ты говоришь (бизон и глр)
[13:59:55] <valexеy> 1984 год
[14:01:04] <valexеy> насколько я понимаю, glr пригоден даже для попыток распарсить естественный язык
[14:01:05] <egp> возможно QTJ просто не осведомлён про бизон был когда статью писал
[14:01:10] <egp> неа
[14:01:22] <egp> для ест языка никакая конечная грамматика не годится
[14:01:39] <egp> это я сто пудов знаю, я лет 15-20 занимаюсь парсингом ЕЯ
[14:02:35] <egp> потому что ЕЯ обменивается с нематематичным внешним миром который физичен психологичен и проч.
[14:03:39] <egp> то есть грамматика ЕЯ включает такую противоречивую сущность, как все миры бытия и также включает всё за пределами всего.
[14:04:32] <egp> Грамматика также включает т.н. "женскую логику" среди всего прочего. :)
[14:04:37] <egp> грамматика ЕЯ*
[14:04:52] <valexеy> грамматика - нет. не путай таки грамматику языка со смыслом написанного.
[14:05:21] <egp> ну если в этом строгом смысле, то грамматика ЕЯ - бесконечна
[14:05:40] <egp> потому что грамматика ЕЯ может быть расширена любым "пользователем" ЕЯ
[14:06:02] <valexеy> равно как и ЯП :-)
[14:06:17] <valexеy> технически проблем расширить грамматику любого ЯП нет никаких
[14:07:41] <egp> любую конечную под-грамматику ЕЯ можно пополнить. И объединение пределов всех последовательностей таких под-грамматик ЕЯ - это бесконечное множество символов.
[14:09:57] <egp> то есть если эн-плюс-первая под-грамматика получена операцией пополнения грамматики из энной под-грамматики, то предел таких под-грамматика при эн, стремяшемся к бесконечности, может быть и бесконечным. при некоторых из операций пополнения.
[14:11:06] <egp> то есть бесконечные грамматики также имеются в множестве-семействе всех грамматик всех ЕЯ.
[14:11:49] <egp> а раз есть бесконечные грамматики, то для них нужна бесконечная компутерная система для их обработки. Таких систем пока что не изобретено.
[14:12:43] <egp> То есть по крайней мере в таких компутерных системах требуется наличие бесконечного количества памяти.
[14:13:13] <egp> такого количества памяти ещё не избретено среди компутерных технологий.
[14:13:50] <egp> так что никакой glr не спасёт отцов русской демократии :)
[14:14:03] <egp> и отцов русского коммунизма тоже не спасёт :)
[14:15:06] <egp> кроме того в современную грамматику ЕЯ входит вся грамматика математики. :))
[14:17:00] <egp> ну и суммарная граммтика всех ЯП также входит в грамматику ЕЯ.
[14:22:49] <egp> и ещё все грамматики, назовём их грамматиками G=G(С, P, t), реализуемые исчислениями С(P, t), индуцируемыми каждой из написанных программ P=P(t), в сумме образуют некое на каждый заданный момент времени t конечное множество грамматик S={G: G belongs_to S, G=G(C, P, t) for some C, P, t}.
[14:23:23] <egp> for a given C, P, t
[14:27:18] <egp> Их я лично называю интерпретивными грамматиками, а это явление я лично называю "интерпретивной семантикой программ P" и "интерпретивной семантикой Sem=Sem(User, P, D, t) входных данных D для заданных данных D=D(P, t) на входе программы P в момент времени t".
[14:28:37] <egp> то есть грубо говоря, каждая заданная программа (точнее, её рантайм-инстанс RI) задаёт некоторую грамматику.
[14:29:08] <egp> я лично называю эту грамматику интерпретивной грамматикой (или операционной грамматикой).
[14:30:16] <egp> Соотв. имеем интерпретивую грамматику и операционную грамматику. Например, любые грязные хаки --- это примеры таких грамматик.
[14:31:03] <egp> просто грязные хаки - это типа "некрасивые грамматики", в отличие от "красивых грамматик".
[14:31:41] <egp> Но это тоже всё-таки грамматики, хоть они и некрасивы.
[14:33:21] <egp> Ещё их можно назвать некрасивами процедурными грамматиками или некрасивыми функциональными грамматиками, в отличие от красивых процедурных грамматик.
[14:34:09] <egp> процедурные/функциональные - это в зависимости от парадигмы, к которой принадлежит данная программа или язык программирования.
[14:34:24] <egp> от парадигмы программирования.
[14:34:55] <egp> Ну и к чему я это всё говорил, ща подумаю...
[14:36:01] <egp> Просто потому говорил, что это явление не описано либо мало описано в научной литературе по грамматикам.
[14:37:29] <egp> Во всяком случае я не встречал литературы по таким индуцируемым грамматикам, то есть по грамматикам, индуцируемым языками программирования и грамматикам. индуцируемым конкретными программами и их рантайм-экземлярами (рантайм-инстансами).
[14:39:56] <egp> Ну и дело в том, что ограниченный (т.е. конечный) диалект ЕЯ вполне возможен для реализации в классе таких процедурных грамматик процедурного программирования или в классе функциональных грамматик функционального программирования.
[14:41:39] <egp> А вот полный диалект ЕЯ --- невозможен для реализации при современном уровне развития технологий, поскольку конечно количество памяти на каждый заданный момент времени при современном уровне развития технологий, и это только одна из имеющихся причин.
[14:42:20] <egp> Причин невозможности реализации полного диалекта ЕЯ.
[14:42:49] <egp> Все причины невозможности реализации полного диалекта ЕЯ я не перечисляю здесь.
[14:44:05] <egp> Опубликую этот лог на ailab.ru
[14:46:45] <egp> valexеy, я один из участников aot.ru и нашего проекта http://sf.net/projects/seman
[14:47:24] <egp> правда код который я законтрибутил - это просто Java JNI wrapper для части АПИ проекта seman.
[14:47:37] <egp> больше пока ничего не законтрибутил.
[14:47:58] <valexеy> ок. гляну
[14:48:59] <egp> joxy - это мой юзернейм на sf
[14:49:31] <valexеy> ok
[14:50:43] <egp> лицензия seman --- GNU Library or Lesser General Public License version 2.0 (LGPLv2)
[14:51:35] <egp> лицензия JNI враппера на данный момент --- http://sourceforge.net/projects/seman-java/
License:
GNU General Public License version 3.0 (GPLv3)
[14:52:05] <valexеy> анализ текстов на естественных языках пока вне сферы моих интересов
[14:52:21] <egp> однако очень даже в сфере моих :)
[14:53:58] <egp> тогда тебе и глядеть эти два под проекта проекта aot.ru нет никакого смысла
[14:54:26] <valexеy> да не, я гляну. вдруг с помощью этого можно сделать что-то вменяемое для форума
[14:54:49] <egp> морфологию русского и немецкого например можно парсить
[14:55:07] <valexеy> и использовать для поиска, да.
[14:55:07] <egp> то есть производить морфологический анализ русских и немецких слов
[14:55:28] <egp> что ещё можно - я в деталях не в курсе, мне только морфоблок требовался для одного дела.
[14:56:16] <egp> и кстати
[14:56:48] <egp> Контора Яндекс купила у AOT.ru право на использование парсеров AOT.ru в проектах Яндекса.
[14:57:02] <valexеy> дык про что я и написал - поиск
[14:57:15] <egp> То есть компоненты, сделанные AOT юзаются Яндексом.
[14:57:49] <egp> то есть Яндекс их заюзал, то есть абсолютно серьёзные компоненты сделаны AOT.
[15:50:35] <egp> valexеy, спасибо за ценную идею
[15:50:46] <valexеy> да пжалста :-)
[15:50:52] <egp> ты меня подтолкнул к началу писания нового проекта по ЕЯ :)
[15:51:07] <valexеy> вахъ!
[15:51:23] <egp> ценная идея заключена вот в этой твоей фразе: "v.: грамматика - нет. не путай таки грамматику языка со смыслом написанного."
[15:52:31] <valexеy> та это ж очевидная банальщина :-)
[15:53:00] <egp> для человека, который абсолютно запутался в сложностях ЕЯ, это свет истины :)
[15:53:29] <egp> это ты всю жизнь возишься с простейшими грамматиками, остался ясен умом, а я - не остался :)
[15:53:53] <egp> ты просто произвёл Матрикс Релоад в моей башке, только и всего :)
[15:54:09] <egp> такие вот дела клёвые.
[15:54:12] <valexеy> :-)
[15:57:18] <egp> Поместил лог беседы тут: http://ailab.ru/forum/obshenie/misli-vslukh/o-konechnikh-formalizovannikh-predstavleniyakh-podmnojestv-eya.html#20162
[15:58:39] <valexеy> ok
[16:25:22] <valexеy> А вот это - круто: http://lenta.ru/news/2012/07/20/passive/
[16:50:09] <egp> valexеy, про что там по ссылке?
[16:50:15] <egp> я не смотрел
[16:51:46] <egp> что-то ценное?
[16:53:16] <egp> ну да, крутейшая фига для вояк
[16:57:51] <egp> гг
[16:58:28] <egp> придумал название для самого-самого главного своего проекта: "МойЭлектронныйДруг" (сокращённо "МЭД") :)
[17:01:09] <egp> http://code.google.com/intl/ru/ пишет:

Новый сайт Google Developers
Мы ведем работу по созданию нового сайта Google Developers по адресу developers.google.com, на котором будут объединены все ресурсы, программы, мероприятия, группы, инструменты и продукты Google для разработчиков. Мы делаем все возможное, чтобы закончить работу в ближайшее время. Вскоре вся информация Google для разработчиков будет доступна на указанном сайте. Сайт code.google.com, на котором вы сейчас находитесь, вновь станет использоваться для хостинга проектов с открытым исходным кодом.
developers.google.com
Ссылка: https://developers.google.com/
[17:04:41] <egp> На первый взгляд щас на сайте developers.google.com ничего интересного не видно.
[17:16:06] <egp> мэду поставил Google Code Labels:
personal-buddy, personal-main-project, personal, umbrella-project
[17:16:19] <valexеy> нужно четко понимать, что не боги горшки обжигают. не стоит от гугла ожидать чего-то эдакого.
[17:17:32] <egp> Labels
personal-buddy, personal-very-very-main-project, personal, umbrella-project
[17:18:11] <egp> Labels
personal-buddy, personal-ultimately-main-project, personal, umbrella-project
[17:18:20] <egp> во, так круче всего :)
[17:18:38] <valexеy> :-)
[17:19:26] <egp> Язык будет называться "Sublanguage".
[17:20:16] <valexеy> подъязык? :-)
[17:21:21] <egp> lf
[17:21:23] <egp> а
[17:21:24] <egp> да
[17:21:40] <egp> Подъязык языка Вселенной! :)
[17:22:29] <valexеy> это можно сказать о любом языке :-)
[17:24:02] <egp> да, ибо это КРУТО!!! :)
[17:38:07] <egp> Нифига себе какой IP адресок гугл прикупил:

google.com [10.0.0.1]

:)
[17:39:12] <egp> тысяча и один :)
[17:44:46] <egp> вначале для МЭДа сделаю апи парсинга оберон-сырцов. В парсер будет передаваться лисенер.
[17:45:33] <egp> бинарно это дллка для винды и других ос
[17:45:41] <egp> и аналогично в других ос
[17:53:56] <egp> Язык Оберон, поддерживаемый этим апи, будет формально называться "MEFSublanguageId1FormalOberon".
[17:55:20] <egp> Точнее так: "MEFSublanguageId1/FormalOberon/Dialect1".
[18:07:03] <egp> И это апи будет 1) семейство ионов  (один из ионов --- набор исходного кода этого апи парсинга оберона, диалекта №1, причём этому набору исходного кода необходимы один или больше обработчиков-ионов, которым он нужен). "Ион" означает "атом, у которого есть dependencies". "Неионизированный атом" означает "атом, у которого нет dependencies". "Атом" означает "неделимая сущность". Неионизированных атомов в этом апи не будет.
[18:08:27] <egp> опечатка. ЧИтать так: 1) семейством ионов  
[18:11:02] <egp> An ion consisting of a single atom is an atomic or monatomic ion; if it consists of two or more atoms, it is a molecular or polyatomic ion.
[18:11:44] <egp> Removal of the electron gives a cation, whereas addition of an electron gives an anion.
[18:11:59] <egp> (из википедии про ионы и катионы и анионы.)
[18:13:08] <egp> То есть говоря про программные ионы, я везде имел в виду катионы.
[18:16:40] <egp> Ещё из Википедии про ионы: "An ion is an atom or molecule in which the total number of electrons is not equal to the total number of protons, giving it a net positive or negative electrical charge. The name was given by physicist Michael Faraday for the substances that allow a current to pass ("go") between electrodes in a solution, when an electric field is applied. It is the transliteration of the Greek participle ἰόν, ión, "going"."
[18:27:09] <egp> Язык "MEFSublanguageId1/FormalOberon/Dialect1" должен: 1) максимально соответствовать имеющейся некоторой версии документа "Oberon Programming Language Report"; 2) быть максимально простым (т.е. никаких прагм, никаких синтаксических наворотов в языке быть не должно); 3) пункт 1 (о соответствии документу "Oberon P.L. Report") приоритетнее и важнее пункта 2 (о простоте).
[18:29:10] <egp> Пункт 1 является нормативным. Пункт 2 менее важен, чем пункт 2.
[18:29:49] <egp> опечатался. Читать так:

 4) Пункт 1 является нормативным. Пункт 2 менее важен,
чем пункт 1.
[18:55:38] <egp> addition to item 1:

Язык "MEFSublanguageId1/FormalOberon/Dialect1" должен:

 1) максимально соответствовать имеющейся некоторой
версии документа "Oberon Programming Language Report"
(см. http://code.google.com/p/buguldey-ai-foss/source/browse/trunk/eclipse_projects/oberon86_1_0_incubation/o2report.htm?spec=svn158&r=43 );

[19:12:54] <egp> addition to item 1:

Though this version of a document o2report.htm ("The Programming Language Oberon-2") lacks a section D5 (which usually contains a graphical  figure), so expect a change of this normative document. I.e. this means that this overall description of an Oberon-parsing API is NOT a normative.