WarmPlace.ru

Поддерживаю Zuf'a и goglus'a. Функции было бы не плохо и переменные эти- локальные

ситуёвина патовая) - голоса поровнялись

ok. Вижу, в голосовании пошел явный перекос ) В таком случае меняю тему опроса - решаем, как оформлять локальные переменные.

вопрос к сторонникам усложнения
- сподвигнет это на написание кучи новых сложных мос4ных программ и волшебных демок?

goglus wrote:вопрос к сторонникам усложнения
- сподвигнет это на написание кучи новых сложных мос4ных программ и волшебных демок?

Да.

Кроме того "усложнение" опционально. Т.е. никто не заставляет пользоваться новыми возможностями, можно остаться на старых.

Голосую за точку.

Мои аргументы:
1. Оператор точка во многих языках указывает на член некой сущности. Например для структур в Си: struct.member=0;
В функции локальная переменная как бы соотносится с именем текущей функции: myfunction.var=0
Опускаем имя функции и получаем мой вариант с точкой.
2. Походий подход используется в Руби, там даже больше символов для имен переменных.
3. Так будет очень легко сделать подсветку синтаксиса для локальных переменных (в частности для Kate). (Впрочем в других случаях тоже можно)

Минус виду пока только один - если вводим float то можно запутпться с синтаксисом:
.O = .0 (точка "О" равно точка ноль, т.е. присваиваем локальной перемнной O значение 0.0)
Но это только в том случае, если такая форма записи цисел с плавающей запятой будет использоваться.

P.S. А вообще голосованием не добиться правды. Решение придется NightRadio принять самостоятельно и даже автоританрно, мы только советуем

Ну опрос я на всякий пожарный делаю.. Толку мало, но кое-какие выводы все равно получаются :)
На счет точки согласен - неплохой вариант. Хотя и в $ есть свои плюсы.
Объясню, что меня заставляет задуматься о целесообразности вводить функции и локальные переменные.
1. На словах это безусловно просто и понятно. Но вот для того, чтобы заточить под это дело компилятор, потребуются немалые усилия. А по ходу еще напрашивается вопрос: не легче ли сделать мелкий и портируемый компилятор Си? :) Ну и естественно, пострадает скорость и размер компилятора Pixilang.
2. В текущем варианте подпрограмма может состоять из одной команды RET или пары присвоений + RET. Причем, это уже на уровне ассемблера (после компиляции в Pixilang2). То есть, очень компактно и, соответственно, быстро. Как только мы введем параметры и локальные переменные - на былую простоту навешаются сохранение/восстановление регистров на границах функции и восстановление указателя стека перед выходом из функции.

А нельзя в новом пиксилэнге реализовать поддержку других графических форматов? В gif-е картинки очень уж отдизереные получаются. А насчет лок.переменных - я за var, т.к. думаю, что видеть код будет легче, чем с точками.
Жду pixilang 3.

Но, ведь все равно, наверное , будет быстрее чем Pixilang1.6?
Как вариант, может быть сделать такой пакет - компилятор и исходник пикси в одном флаконе, при запуске этого файла - меню выбора конфигурации пикси - кому нужны ф-и и лок. переменные -ставит галочку и на enter жмет. На выходе - получаем исполняемый файл pixilang3 (кому какой нужен). Как вариант.

Поддержку новых форматов только в виде библиотек, написанных на самом Pixilang. Есть мысли даже GIF вынести из пикси... Просто это лишние объемы компилятора.
Должно быть быстрее, чем Пикси 1.6... В большинстве случаев все будет гуд. Проблема скорости может всплыть только в реально требовательных задачах - например, в пиксельных шейдерах.
Функции и лок. переменные либо будут либо не будут :) Промежуточным вариантом мы окончательно угробим простоту языка.

Да, необходимый минимум очень быстрых команд (в первую очередь). А только потом- несколько подключаемых библиотек для реализации различных "примочек". Вот еще идейка: к контейнеру pixi контейнер sprite, чтобы каждый экземпляр спрайта имел свой номер, pixi-образ, координаты Х,У и может быть флажок transparency 1 байтовый. И, соответственно, команды на создание экземпляра спрайта, отображение экз. спрайта, определение пересечения непрозрачных областей спрайта с другим спрайтом (идент. по номерам спрайтов). Но это как идея, для будущих версий (и то если народ поддержит и если это не противоречит основной идее языка), а основное, конечно-скорость!

NightRadio wrote:Поддержку новых форматов только в виде библиотек, написанных на самом Pixilang. Есть мысли даже GIF вынести из пикси... Просто это лишние объемы компилятора.

А юзер получит возможность сам писать такие библиотеки и компилить их в байткод (чтобы работали быстрее), или они будут в виде обычного txt-файла?

Байт-код или промежуточное представление пикси-кода - это уже отдельный вопрос :) Дойдем и до него.

intre wrote:А насчет лок.переменных - я за var, т.к. думаю, что видеть код будет легче, чем с точками.
Жду pixilang 3.

Да, точка будет не очень заметна. Но это и не так уж плохо, на мой взгляд. Не отвлекает от сути вещей.
Вариант с var мне не нравится, толком даже не пойму почему. (Наверное вызывает неприятные ассоциации с visual basic и javascript). Ввод ключевого слова var для локальных переменных идет в разрез с концепцией "использовал, значит объявил", которая применяется в языке.
Хотя по большому счету нет разницы между точкой и var. Это всего лишь "синтаксический сахар" (насколько я понимаю это выражение)

J3d1 wrote:Вот еще идейка: к контейнеру pixi контейнер sprite, чтобы каждый экземпляр спрайта имел свой номер, pixi-образ, координаты Х,У и может быть флажок transparency 1 байтовый. И, соответственно, команды на создание экземпляра спрайта, отображение экз. спрайта, определение пересечения непрозрачных областей спрайта с другим спрайтом (идент. по номерам спрайтов). Но это как идея, для будущих версий (и то если народ поддержит и если это не противоречит основной идее языка), а основное, конечно-скорость!

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

Да, скорее классы, да и структуры, но это очень страшные слова... И видимо трудно реализуемые, если серьезно. Опять же концепция языка позволит ли.

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