Oberon space
General Category => Общий раздел => Тема начата: Geniepro от Июль 26, 2013, 06:18:44 am
-
OberonJS - отказать. (http://nponeccop.livejournal.com/333439.html)
Посмотрел я на http://oberspace.dyndns.org/oberonjs.html
MODULE test;
IMPORT JS;
PROCEDURE Foo*;
VAR a : ARRAY 10 OF REAL;
BEGIN
JS.alert("Hello, World!")
END Foo;
BEGIN
END test.Транслируется в:
var RTL$ = {
makeArray: function (/*dimensions, initializer*/){
var forward = Array.prototype.slice.call(arguments);
var result = new Array(forward.shift());
var i;
if (forward.length == 1){
var init = forward[0];
if (typeof init == "function")
for(i = 0; i < result.length; ++i)
result[i] = init();
else
for(i = 0; i < result.length; ++i)
result[i] = init;
}
else
for(i = 0; i < result.length; ++i)
result[i] = this.makeArray.apply(this, forward);
return result;
}
};
var JS = function(){return this;}();
var test = function (){
function Foo(){
var a = RTL$.makeArray(10, 0);
JS.alert("Hello, World!");
}
}();По пунктам:
1. человекочитаемый выходной код - есть (идентификаторы сохраняются)
2. старый дизайн выходного кода - нет (отличается семантика массивов, из-за чего появляется шлак в виде RTL$ вместо new Array(10))
3. новая система типов - есть*
4. новый синтаксис - есть*
5. компактный новый язык - есть*
* - но это же 1950-е годы, Алгол-58
По списку - [1,3,4,5]
Это было в продолжение его поста "HNC и Javascript" (http://nponeccop.livejournal.com/332098.html):
Внезапно у моего вечно мертвого HNC (https://github.com/kayuri/HNC/wiki) появилось второе после сей поле для применения: Javascript. С и JS оба а) неизбежны в своих областях применения б) убоги.
Интересно, однако, что если при компиляции в Си среди конкурентов имеем сплошь страх и ужас (генерация неидиоматического кода, попытки изменить семантику), при компиляции в JS всё не так плохо: некоторые изобретатели языков, компилирующихся в JS, осознают необходимость генерировать на выходе качественный код, а не кашу.
Также интересно, что предпринимаются попытки и выделить каноническое подмножество старого языка, правда, только в виде замены 100500 возможных в JS объектных моделей на захардкоженную в кодогенератор одну каноническую. Например, декларации классов в CoffeeScript и MS TypeScript.
Вот мне интересно, есть ли языки, компилирующихся в JS и удовлетворяющие требованиям:
1. человекочитаемый выходной код
2. старый дизайн выходного кода (никаких остающихся на выходе ленивостей, алгебраиков, гигантских говнорантаймов, идиотского кода вроде f.call(null) и хуй-эр-пэ)
3. новая система типов
4. новый синтаксис
5. компактный новый язык
Coffeescript - [1, 2, 4]
TypeScript - [1, 2, 3]
Ur, Fay, Roy, Elm, Haxe, Agda, Idris - [3, 4, 5]
ClosureScript - [4, 5]
Erlang JavaScript compiler - [1, 2, 4, 5]
OberonJS - [1, 3, 4, 5]
Кто-нибудь ещё что-нибудь стоящее внимания знает из 100500 языков в списке (https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS)?
Пока получается, что 2 плохо дружит с 5.
-
Так это, Влад, зачем компилировать код
VAR a : ARRAY 10 OF REAL;как
var a = RTL$.makeArray(10, 0);вместо
var a = new Array(10);?
-
Я там накатал ответ. Не по мелочам, а так, обзорно.
-
Так это, Влад, зачем компилировать код
VAR a : ARRAY 10 OF REAL;как
var a = RTL$.makeArray(10, 0);вместо
var a = new Array(10);?
new Array(10) - не инитит элементы. Причем это надо даже для всяких INTEGER/REAL, не только для RECORD, иначе в рантайме оно пойдет в разнос (там будет жабаскриптовый "undefined").
Можно конечно заявить об undefined behavior при обращении к непроиниченному элементу... но не хочется. Поэтому все инитится, не смотря на то, что репорт молчит как всегда по поводу таких нюансов.
-
Я там накатал ответ. Не по мелочам, а так, обзорно.
Я прикрутил модули, но их надо допиливать - работает только простейший сценарий импорта вышестоящего по тексту модуля.
-
Я там накатал ответ. Не по мелочам, а так, обзорно.
Я прикрутил модули, но их надо допиливать - работает только простейший сценарий импорта вышестоящего по тексту модуля.
Круто! Надо будет пощупать.
-
По топику, у меня появилось ощущение, что смысловая связь между названием оригинальной статьи и ее содержанием достаточно слабовата - что то типа мыслей в слух...
-
По топику, у меня появилось ощущение, что смысловая связь между названием оригинальной статьи и ее содержанием достаточно слабовата - что то типа мыслей в слух...
Вы имеете в виду название "OberonJS - отказать."?
Этот Andy Melnikov (http://nponeccop.livejournal.com/profile) несколько лет пилит свой собственный язык HNC (для замены с++), и решил приспособить его для генерации яваскриптного кода. Но дл начала он стал интересоваться, какие есть ещё реализации разных языков для JS. Составил себе список требований из пяти пунктов, я ему посоветовал глянуть на OberonJS. Посмотрев, Melnikov его забраковал почему-то...
-
Kotlin'у он тоже отказал: http://nponeccop.livejournal.com/333825.html
-
Вы имеете в виду название "OberonJS - отказать."?
Этот Andy Melnikov (http://nponeccop.livejournal.com/profile) несколько лет пилит свой собственный язык HNC (для замены с++), и решил приспособить его для генерации яваскриптного кода. Но дл начала он стал интересоваться, какие есть ещё реализации разных языков для JS. Составил себе список требований из пяти пунктов, я ему посоветовал глянуть на OberonJS. Посмотрев, Melnikov его забраковал почему-то...
Точно. Слабые логические связи, странные требования, и еще более странная методика оценки.
-
http://nponeccop.livejournal.com/333439.html?thread=3092863#t3092863
-
http://nponeccop.livejournal.com/333439.html?thread=3092863#t3092863
"по итогам претензий" можно оставить разбираться г-на А. Мельникова самому со своими "заскоками" не претендуя ни на его "честь или достоинство" уже после того, когда он начал говорить о качестве создаваемого js - кода (после ваших , Алексей , разьяснений по поводу текущего статуса и направленности проекта)
-
Точно. Слабые логические связи, странные требования, и еще более странная методика оценки.
Ну хз, кто его знает, может он когда-нить сделает что-то своё в этом духе, лучше чем всё остальное...
-
Kotlin'у он тоже отказал: http://nponeccop.livejournal.com/333825.html
Ну котлиновский компилятор и правда выдал какую-то жуть непонимабельную...
-
Kotlin'у он тоже отказал: http://nponeccop.livejournal.com/333825.html
Ну котлиновский компилятор и правда выдал какую-то жуть непонимабельную...
а что разве создатели котлина ставили своей целью генерить конечный js- код "высокой понимабильности"?
-
а что разве создатели котлина ставили своей целью генерить конечный js- код "высокой понимабильности"?
Не знаю, возможно что и нет. Но этому Мельникову это нужно -- его право, почему бы и нет...
-
Будут ли у вас проблемы с производительностью - только реалистичные бенчмарки могут показать, которых пока нет ни у меня, ни у вас.
Кстати, действительно, есть же всякие бенчмарки -- хотя бы те же дристоун/ветстоун из пакета XDS Modula-2/Oberon-2. Неплохо было бы попробовать их портировать -- глядишь всякие баги компилятора посыпятся как из ведра ))))
-
а что разве создатели котлина ставили своей целью генерить конечный js- код "высокой понимабильности"?
Не знаю, возможно что и нет. Но этому Мельникову это нужно -- его право, почему бы и нет...
бог с ним.. а haxe он рассматривал? :D
-
а haxe он рассматривал? :D
Вроде да, в его списке он указан:
Ur, Fay, Roy, Elm, Haxe, Agda, Idris - [3, 4, 5]
-
var a = RTL$.makeArray(10, 0);вместо
var a = new Array(10);?
Один из возможных вариантов решения проблемы - двигать в сторону asmJS и делать вообще все через массивы (включая рекорды). Причем не через традиционный Array, а через массивы байтов. Тогда не нужна инициализация. Но читаемость сильно пострадает - "r.field := 123" будет транслироваться во что-то типа "r[8/*field*/] = 123".
-
var a = RTL$.makeArray(10, 0);вместо
var a = new Array(10);?
Один из возможных вариантов решения проблемы - двигать в сторону asmJS и делать вообще все через массивы (включая рекорды). Причем не через традиционный Array, а через массивы байтов. Тогда не нужна инициализация. Но читаемость сильно пострадает - "r.field := 123" будет транслироваться во что-то типа "r[8/*field*/] = 123".
Ненене! Не надо так рекорды делать!
-
var a = RTL$.makeArray(10, 0);вместо
var a = new Array(10);?
Один из возможных вариантов решения проблемы - двигать в сторону asmJS и делать вообще все через массивы (включая рекорды). Причем не через традиционный Array, а через массивы байтов. Тогда не нужна инициализация. Но читаемость сильно пострадает - "r.field := 123" будет транслироваться во что-то типа "r[8/*field*/] = 123".
а толку :D Мельникову один хрен этим не угодишь.
-
а толку :D Мельникову один хрен этим не угодишь.
Вобщем да - получение оптимального кода на выходе далеко не основная цель проекта на данном этапе.
-
Вобщем да - получение оптимального кода на выходе далеко не основная цель проекта на данном этапе.
Вообще-то было бы хорошо заставить кодогенератор выдавать код, пригодный для AsmJS, но, конечно, без извращений над записями...
-
Вообще-то было бы хорошо заставить кодогенератор выдавать код, пригодный для AsmJS, но, конечно, без извращений над записями...
"Извращения над записями" как раз и дадут наибольший прирост в производительности :) Потому что уйдет динамика с точки зрения нижележащей машины. И объектов для GC тоже будет сильно меньше.
-
Если подумать, как раз представление Обероновской записи в виде map-а "ключ"-"значение" (каковым является любой JS-объект) и является извращением :)
-
Представление у записи классическое. Это реализация у неё "ключ-значение". И такая реализация была выбрана исходя из критерия читабельности. Как сделать, если важнее производительность, Влад тоже показал, но читабельность для него важнее.
-
Представление у записи классическое. Это реализация у неё "ключ-значение". И такая реализация была выбрана исходя из критерия читабельности. Как сделать, если важнее производительность, Влад тоже показал, но читабельность для него важнее.
Тут не только читабельность, но и интероперабельность с чистым js-кодом без маршалинга.
-
http://nponeccop.livejournal.com/333439.html?thread=3092863#t3092863
"по итогам претензий" можно оставить разбираться г-на А. Мельникова самому со своими "заскоками" не претендуя ни на его "честь или достоинство" уже после того, когда он начал говорить о качестве создаваемого js - кода (после ваших , Алексей , разьяснений по поводу текущего статуса и направленности проекта)
Честно говоря, я так и не понял, что он имел в виду, говоря про "явный бред, порочащий мою честь и достоинство" (http://nponeccop.livejournal.com/333439.html?thread=3092863#t3092863). Неужели только то, что я постарался в точности передать название его ЖЖ?
-
Если подумать, как раз представление Обероновской записи в виде map-а "ключ"-"значение" (каковым является любой JS-объект) и является извращением :)
Фигня. Ни в каком месте это не противоречит Oberon report'у. Запись это вообще всегда отображение (map как минимум времени компиляции) имени поля на её значение. Как именно это реализовано - дело десятое.
И вообще, быть может у тебя еще и локальные переменные должны лежать на стеке, представляющем собой непрерывную область памяти?! ;-)
-
Если подумать, как раз представление Обероновской записи в виде map-а "ключ"-"значение" (каковым является любой JS-объект) и является извращением :)
Фигня. Ни в каком месте это не противоречит Oberon report'у.
Очевидно, что Илья имел ввиду не репорт, и интерпретацию с точки зрения современного железа. Никаких мэпов там нет, а есть указательные регистры и смещения...
-
Если подумать, как раз представление Обероновской записи в виде map-а "ключ"-"значение" (каковым является любой JS-объект) и является извращением :)
Фигня. Ни в каком месте это не противоречит Oberon report'у.
Очевидно, что Илья имел ввиду не репорт, и интерпретацию с точки зрения современного железа. Никаких мэпов там нет, а есть указательные регистры и смещения...
Да в железе даже переменных нет, да и ряда типов (встроенных) там тоже может не оказаться. Не говоря уже о записях и проч. Ну и вообще, не меньший изврат это пихать переменные в стек (в ОЗУ, то есть в медленную память) когда регистры есть. Вообще на регистровых процессорах использовать (эмулировать, да) стек - это извращение ничуть не хуже записей через js-объекты :-)
Jit-компиляторы жабаскрипта сейчас умные, кто знает в каком конкретно видео они js-объекты там держат? И в каком виде они там будут их держать через скажем год. Вполне может оказаться, что они там научатся (если уже не научились) конвертировать текущее представление в наиболее удобоваримую, для данного использования, форму. В том числе и в непрерывный шмат памяти.
Вообще, нефиг тут преждевременную оптимизацию городить - ведь уже ясно что оно гаратированно добавит разнообразных геморроев (один маршалинг чего стоит!), а вот профиты не очевидны.
-
Jit-компиляторы жабаскрипта сейчас умные, кто знает в каком конкретно видео они js-объекты там держат? И в каком виде они там будут их держать через скажем год. Вполне может оказаться, что они там научатся (если уже не научились) конвертировать текущее представление в наиболее удобоваримую, для данного использования, форму. В том числе и в непрерывный шмат памяти.
Угу. И всё больше внизу слоёв, про которые можно только догадываться, как они работают, которые реализованы только 2-3 поставщиками, инвестировавшими в это годы, и которые уже потом невозможно выкинуть, один раз подсев.
-
Jit-компиляторы жабаскрипта сейчас умные, кто знает в каком конкретно видео они js-объекты там держат? И в каком виде они там будут их держать через скажем год. Вполне может оказаться, что они там научатся (если уже не научились) конвертировать текущее представление в наиболее удобоваримую, для данного использования, форму. В том числе и в непрерывный шмат памяти.
Угу. И всё больше внизу слоёв, про которые можно только догадываться, как они работают, которые реализованы только 2-3 поставщиками, инвестировавшими в это годы, и которые уже потом невозможно выкинуть, один раз подсев.
Илья, это вы про себя и ББ ? :D
-
Вы издеваетесь, что ли?
Я всю рантайм-часть (ядро, метаинформацию, отладочные инструменты) перебрал ещё в 2006-м за месяц... Когда сделал Active BB. И документацию на ядро подробную написал, теперь доступную всем.
Компилятор и ГУЙ, допустим, я не трогал в силу того, что мне это не было нужно, а инвестировать время просто так - смысла нет.
Есть задачи типа "появилась возможность - вложили усилия - всё работает по-новому без переписывания". Компилятор и реализация ГУЯ относятся именно к этому типу.
А райнтаймы-фреймворки - нет, ибо они оказывают сквозное влияние на то, что ты над ними разрабатываешь.
-
:) Да нет.. не издеваюсь - а просто моделирую следующую ситуевину , с позиции возможного вашего приемника со стороны заказчика (которому вы делали в течении нескольких лет совтину, но потом разбежались.. и остался он бедный с кучей кода который необходимо сопровождать) нанятого им для поддержания и развития созданного вами кода на бб.
-
И документацию на ядро подробную написал, теперь доступную всем.
Кстати, а где она лежит? Любопытно было бы прочесть.
-
http://www.oberoncore.ru/wiki/blackbox/addn_docu