![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Хочется странного
Есть кроссплатформенные языки типа Java. Но они все как назло - интерпретаторы.
Есть кроссплатформенные библиотеки к компиляторам. Но они все как назло - не стандарт языка.
А хочется странного. Хочется, чтобы многие вещи стали стандартом для компилируемого языка. Хочется языка типа C++, но с кое-какими изменениями. Могу я ведь помечтать, а? :)
Я напишу только один пункт моих "мечт".
1. Хочу, чтобы были стандартные средства работы с thread-ами - мутексы, треды, сигналы... Причем, даже не в форме библиотек, а в форме ключевых слов, дополнительных конструкций языка.
Например:
int a, b, c;
mutex x for a, b;
- чтобы компилятор завел мутекс x и использовал его сам, автоматически при обращениях к переменным a, b. Чтобы компилятор сам оптимизировал это дело. Например вот для такой серии:
a++;
c = 4;
b-= 2;
- хороший компилятор должен "понять", что хотя переменная c и не требует защиты мутексом, но присвоение занимает мало времени, а потому весь фрагмент лучше обрамить одной парой x.lock ... x.unlock.
Далее, чтобы компилятор снял с программиста заботу о разблокировании мутексов при передаче управления (исключения, return и т.п.)
Треды тоже... каждая операционка кто во что горазд. Надо единую хрень, встроенную в йезыг. Как-то так:
void myfunc(int x, char *y)
{
...
}
- Это просто функция. Параметры произвольные.
А потом так:
thread t= myfunc(99, "Loading...");
или так:
thread myfunc(99, "Loading...");
- то есть, чтобы произвольную функцию можно было средствами самого языка вызвать в отдельном треде как тред. И передать треду параметры не через жопу, а просто как параметры функции. В первом варианте синтаксиса еще и вернуть идентификатор треда.
Опционально чтобы у типа thread был какой-то разумный набор операций (suspend/resume/kill...). Как минимум - сравнение тредов, узнавание id текущего треда (ключевое слово thread.this ), узнавание id треда, который создал этот тред (ключевое слово thread.parent ).
Ну и, наконец, к тредам добавить средства синхронизации и передачи данных между тредами. Что-нибудь вроде такого:
Пояснения. Надо, чтобы содержимое любой переменной можно было отослать в другой тред. Как только тот тред доходит до нужного места, он забирает "подарочек". Если подарка еще нет, тот тред ждет. Отсылающий тред ничего не ждет, содержимое переменной копируется в скрытый буфер. Если не хочется копировать много данных, то отсылаем указатель.
...
class MyData
{
int a;
char *c;
};
...
MyData b;
MyData result;
...
thread t = myfunc(99, "Loading...");
...
b.a= 1; //заполняем данные в "подарке"
b >> t; /*отсылаем "подарок", какие-то дополнительные данные, которые
на момент вызова myfunc еще не были готовы */
...
result << t; //забираем результаты исполнения треда, ждем если надо
void myfunc(int x, char *y)
{
...
MyData b;
MyData result;
...
//берем какие-то дополнительные параметры
b << thread.parent; /* thread.parent - ключевое слово, означает тред, который создал этот тред */
...
//отсылаем результаты
result >> thread.parent;
}
Помечтаем, а? :)
Есть кроссплатформенные библиотеки к компиляторам. Но они все как назло - не стандарт языка.
А хочется странного. Хочется, чтобы многие вещи стали стандартом для компилируемого языка. Хочется языка типа C++, но с кое-какими изменениями. Могу я ведь помечтать, а? :)
Я напишу только один пункт моих "мечт".
1. Хочу, чтобы были стандартные средства работы с thread-ами - мутексы, треды, сигналы... Причем, даже не в форме библиотек, а в форме ключевых слов, дополнительных конструкций языка.
Например:
int a, b, c;
mutex x for a, b;
- чтобы компилятор завел мутекс x и использовал его сам, автоматически при обращениях к переменным a, b. Чтобы компилятор сам оптимизировал это дело. Например вот для такой серии:
a++;
c = 4;
b-= 2;
- хороший компилятор должен "понять", что хотя переменная c и не требует защиты мутексом, но присвоение занимает мало времени, а потому весь фрагмент лучше обрамить одной парой x.lock ... x.unlock.
Далее, чтобы компилятор снял с программиста заботу о разблокировании мутексов при передаче управления (исключения, return и т.п.)
Треды тоже... каждая операционка кто во что горазд. Надо единую хрень, встроенную в йезыг. Как-то так:
void myfunc(int x, char *y)
{
...
}
- Это просто функция. Параметры произвольные.
А потом так:
thread t= myfunc(99, "Loading...");
или так:
thread myfunc(99, "Loading...");
- то есть, чтобы произвольную функцию можно было средствами самого языка вызвать в отдельном треде как тред. И передать треду параметры не через жопу, а просто как параметры функции. В первом варианте синтаксиса еще и вернуть идентификатор треда.
Опционально чтобы у типа thread был какой-то разумный набор операций (suspend/resume/kill...). Как минимум - сравнение тредов, узнавание id текущего треда (ключевое слово thread.this ), узнавание id треда, который создал этот тред (ключевое слово thread.parent ).
Ну и, наконец, к тредам добавить средства синхронизации и передачи данных между тредами. Что-нибудь вроде такого:
Пояснения. Надо, чтобы содержимое любой переменной можно было отослать в другой тред. Как только тот тред доходит до нужного места, он забирает "подарочек". Если подарка еще нет, тот тред ждет. Отсылающий тред ничего не ждет, содержимое переменной копируется в скрытый буфер. Если не хочется копировать много данных, то отсылаем указатель.
...
class MyData
{
int a;
char *c;
};
...
MyData b;
MyData result;
...
thread t = myfunc(99, "Loading...");
...
b.a= 1; //заполняем данные в "подарке"
b >> t; /*отсылаем "подарок", какие-то дополнительные данные, которые
на момент вызова myfunc еще не были готовы */
...
result << t; //забираем результаты исполнения треда, ждем если надо
void myfunc(int x, char *y)
{
...
MyData b;
MyData result;
...
//берем какие-то дополнительные параметры
b << thread.parent; /* thread.parent - ключевое слово, означает тред, который создал этот тред */
...
//отсылаем результаты
result >> thread.parent;
}
Помечтаем, а? :)
no subject
Ну кстати видел:
http://haskell.org/haskellwiki/Haskell
http://caml.inria.fr/resources/index.en.html
http://smarteiffel.loria.fr/
http://www.erlang.org/
http://www.rapideuphoria.com/index.html
Кое что из них может компилироваться.
no subject
no subject
Несамостоятельность это ты о чем? Многие из перечисленных мною написаны на себе.
no subject
несамостоятельность - значит, нужна среда исполнения: "framework", виртуальная машина и т.п.
no subject
А от несамостоятельности вообще никуда не избавиться, на слишком разных платформах это все работает.
no subject
В принципе, может быть и что-то среднее: С++ в форме JIT :)
no subject
Сначала компилируются макросы, которые затем генерят код, который компилируется в код виртуальной машины, при запуске докомпилирующийся в нативный. И все это со строгой типизацией и автоматическим выводом типов.
no subject
no subject
no subject
no subject
это неправильно. компилятор делает синтаксический анализ, потом идёт билдование - собирание разных частей и т.д. - все это относительно сложные задачи, а jitкомпилятор компилирует не из текста, а из БАЙТКОДА - т.е. примитивный маппинг, что делается гораздо быстрее, плюс технология кеширования - т.е. компиляция идёт всего один раз, а потом используется бинарник из кеша.
no subject
(Anonymous) 2008-10-09 07:30 pm (UTC)(link)Эти интерпретаторы умеют либо компилироватся в С либо как вариант прилинковывать программу к интерпретатору.
no subject
невозможность отлова всех синтаксических ошибок во _всем_ объеме кода
пока управление по этой ветке кода не пройдет - интерпретатор ни гугу :(