Концепция Pixilang 3. Функции
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Концепция Pixilang 3. Функции
Предлагаю начать обсуждение концепции новой версии языка Pixilang. Третьей. Почему не второй? Потому что версия 2 при всех кардинальных изменениях внутренней структуры, по синтаксису все-таки принадлежит первой ветке языка. А вот версия 3 будет иметь глобальные изменения и скорее всего не сможет обеспечить полную совместимость с предыдущими версиями - но это неизбежно. Просто много уже всяких идей накопилось - надо реализовывать. Язык должен получиться более мощным, но при этом не должен быть сложнее чем Pixilang 1 и 2. То есть, клонирования Си мы все-таки избежим :)
Итак.. функции.
Далее идет моё предложение.
Функция - это та же подпрограмма, только описанная более явно и имеющая входные параметры (опционально), локальные переменные (опционально) и выходное значение (опционально).
Вот таким образом будем объвлять функцию:
FUNCTION myfunction
{
код функции
}
Если нужны параметры, делаем так:
FUNCTION myfunction
{
parameters( x, y, z )
код функции. в нем параметры x,y,z можно использовать как обычные переменные
}
Если нужны локальные переменные, то так:
FUNCTION myfunction
{
parameters( x, y, z )
local( a, b, c ) //Теперь a,b,c - локальные переменные, определенные только для этой функции. Другие функции эти переменные не увидят.
код функции
}
Функция может возвратить значение таким образом:
FUNCTION myfunction
{
код функции
ret 32 //Возвращаем значение 32
}
Далее в программе можно вызывать функцию, как обычную подпрограмму, и даже передавать ей параметры вот таким образом:
myfunction( 12, 33, x, y )
При этом количество параметров может быть любым и даже если в определении функции эти параметры не предусмотрены, ошибки не будет - перед выходом из функции все принятые параметры освобождаются.
Как и прежде, функции можно задавать быстро прямо в коде программы по типу: myfunction = { код функции }
Чтобы не создавать путаницу, вообще исключаем понятие подпрограммы. Оставляем только функции.
Конструкции типа "SUBPROGRAM: bla bla bla ret" так же запрещаем. Теперь метки - это только метки для перехода командой go/goto. Причем метку нельзя использовать как переменную и получать/изменять её значение - это для того, чтобы никому не пришло в голову использовать метку как функцию.
Итак.. функции.
Далее идет моё предложение.
Функция - это та же подпрограмма, только описанная более явно и имеющая входные параметры (опционально), локальные переменные (опционально) и выходное значение (опционально).
Вот таким образом будем объвлять функцию:
FUNCTION myfunction
{
код функции
}
Если нужны параметры, делаем так:
FUNCTION myfunction
{
parameters( x, y, z )
код функции. в нем параметры x,y,z можно использовать как обычные переменные
}
Если нужны локальные переменные, то так:
FUNCTION myfunction
{
parameters( x, y, z )
local( a, b, c ) //Теперь a,b,c - локальные переменные, определенные только для этой функции. Другие функции эти переменные не увидят.
код функции
}
Функция может возвратить значение таким образом:
FUNCTION myfunction
{
код функции
ret 32 //Возвращаем значение 32
}
Далее в программе можно вызывать функцию, как обычную подпрограмму, и даже передавать ей параметры вот таким образом:
myfunction( 12, 33, x, y )
При этом количество параметров может быть любым и даже если в определении функции эти параметры не предусмотрены, ошибки не будет - перед выходом из функции все принятые параметры освобождаются.
Как и прежде, функции можно задавать быстро прямо в коде программы по типу: myfunction = { код функции }
Чтобы не создавать путаницу, вообще исключаем понятие подпрограммы. Оставляем только функции.
Конструкции типа "SUBPROGRAM: bla bla bla ret" так же запрещаем. Теперь метки - это только метки для перехода командой go/goto. Причем метку нельзя использовать как переменную и получать/изменять её значение - это для того, чтобы никому не пришло в голову использовать метку как функцию.
Re: Концепция Pixilang 3. Функции
Предложенные конструкции для параметров и локальных переменных вызывают вопросы:
Это будет очень не удобно. Да и выглядит не элегантно.
Замечания:
1. Ключевое слово function лучше с маленькой буквы. Чисто практически неудобно шифт зажимать лишний раз. (Хотя, это чистая вкусовщина)
2. Параметры передаем в скобках, сразу после имени функции. Это естественный способ, пришедший к нам из математики. Не надо городить огород со всякими parameters(...) и т.п.
3. Конструкция local(...) тоже выглядит не красиво. Выглядит как команда (функция), но при этом делает какие-то магические действия по объявлению локальных переменных, что вводит лишние исключения и усложняет логику (даже философию) языка. Можно поспорить с видимостью глобальных переменных внутри функции. К примеру, в php в функциях не видно глобальных переменных. Чтобы их увидеть нужно добавить специальную конструкцию вида "global $var1, $var2;". Можно тоже похожим образом сделать, но мне кажется предложенный мной способ является наиболее естественным.
Мой вариант:
В остальном согласен.
Многим может показаться, что предложенный мною способ слишком смахивает на Си. Но это и наиболее близкий к математическому эталону способ. К тому же он красив и удобен, как мне кажется. Ведь задача пиксиланга быть простым и красивым, а не "быть непохожим на Си любой ценой".
Кстати можно даже скобок не писать при вызове функции:
Такое практикуется в Ruby. Скобки при вызове функции в этом языке опциональны.
P.S. Пускай еще остальные выскажутся, может мое мнение слишком уж испорчено си-подобным синтаксисом
Code: Select all
parameters( x, y, z )
local( a, b, c )
Замечания:
1. Ключевое слово function лучше с маленькой буквы. Чисто практически неудобно шифт зажимать лишний раз. (Хотя, это чистая вкусовщина)
2. Параметры передаем в скобках, сразу после имени функции. Это естественный способ, пришедший к нам из математики. Не надо городить огород со всякими parameters(...) и т.п.
3. Конструкция local(...) тоже выглядит не красиво. Выглядит как команда (функция), но при этом делает какие-то магические действия по объявлению локальных переменных, что вводит лишние исключения и усложняет логику (даже философию) языка. Можно поспорить с видимостью глобальных переменных внутри функции. К примеру, в php в функциях не видно глобальных переменных. Чтобы их увидеть нужно добавить специальную конструкцию вида "global $var1, $var2;". Можно тоже похожим образом сделать, но мне кажется предложенный мной способ является наиболее естественным.
Мой вариант:
Code: Select all
a=1
b="test"
c=sin(0)
function myfunction( x, y, z )
{
d = 67 // Локальная переменная
v = d*a+c // v, d - локальные переменные, a и c - глобальные
v = v / (x+y+z) // x, y, z - параметры функции, для пользователя ведут себя как локальные переменные
ret v // возврат значения
}
x = myfunction()
// объявление функции "на лету"
mysecondfunction(p1, p2) = {ret p1+p2*256}
Многим может показаться, что предложенный мною способ слишком смахивает на Си. Но это и наиболее близкий к математическому эталону способ. К тому же он красив и удобен, как мне кажется. Ведь задача пиксиланга быть простым и красивым, а не "быть непохожим на Си любой ценой".
Кстати можно даже скобок не писать при вызове функции:
Code: Select all
myfunction a,b,c
P.S. Пускай еще остальные выскажутся, может мое мнение слишком уж испорчено си-подобным синтаксисом
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Re: Концепция Pixilang 3. Функции
По поводу глобальных и локальных переменных.
Не соглашусь с предложенным, т.к. тут как раз таки возникнут вопросы.
Например, пользователь пишет
Человек, изучающий программирование будет недоумевать, почему же принт не выводет 67 :)
Безусловно, пишутся четкие правила и т.д. Но уровень сложности языка неминуемо повышается.
Если делать по подобию php (все локальные, глобальные по запросу), то это получается почти тоже самое, что я предложил с ключевым словом local(), только наоборот (все глобальные, локальные по запросу) :)
С параметрами в скобках после имени функции я вроде бы согласен.. Но пока не понятно, как в таком случае делать быстрое объявление функций с параметрами. Вариант mysecondfunction(p1, p2) = {ret p1+p2*256} вроде бы проясняет ситуацию, но это правильно с точки зрения математики, не с точки зрения Пикси :) То есть, это вроде бы обычное присвоение a = { xxx }, но при этом кусок функции выдернут из неё и прилеплен к переменной a :)
Еще есть вот такой вариант:
А на счет вызова функций без скобок - это теоретически возможно, но нужно проверить... ибо тут в большей степени от генератора парсера зависит, съест он такие правила или выдаст предупреждение о возможных конфликтах... Ну и на самом деле, лучше уж пусть единообразно все будет - в скобках =)
Не соглашусь с предложенным, т.к. тут как раз таки возникнут вопросы.
Например, пользователь пишет
Code: Select all
function myfunc
{
d = 67
}
myfunc()
print( "$d" )
Безусловно, пишутся четкие правила и т.д. Но уровень сложности языка неминуемо повышается.
Если делать по подобию php (все локальные, глобальные по запросу), то это получается почти тоже самое, что я предложил с ключевым словом local(), только наоборот (все глобальные, локальные по запросу) :)
С параметрами в скобках после имени функции я вроде бы согласен.. Но пока не понятно, как в таком случае делать быстрое объявление функций с параметрами. Вариант mysecondfunction(p1, p2) = {ret p1+p2*256} вроде бы проясняет ситуацию, но это правильно с точки зрения математики, не с точки зрения Пикси :) То есть, это вроде бы обычное присвоение a = { xxx }, но при этом кусок функции выдернут из неё и прилеплен к переменной a :)
Еще есть вот такой вариант:
Code: Select all
function myfunc( p1, p2, x, y, z )
{
здесь p1, p2 - параметры функции, а x,y,z - локальные переменные, которые могут одновременно быть и параметрами
}
myfunc( 23, 33 )
Re: Концепция Pixilang 3. Функции
Когда я изучал программирование этот вопрос для меня был кристально ясен. d - не видно, т.к. d принадлежит функции, а цель создания функции - энкапсулировать некоторые действия из кода основной программы. Соответственно переменные в функции являются локальными.NightRadio wrote:По поводу глобальных и локальных переменных.
Не соглашусь с предложенным, т.к. тут как раз таки возникнут вопросы.
Например, пользователь пишетЧеловек, изучающий программирование будет недоумевать, почему же принт не выводет 67Code: Select all
function myfunc { d = 67 } myfunc() print( "$d" )
php я привел лишь в качестве примера, мне не кажется его подход оправданным.
Нужно провести опрос начинающих как раз для того чтобы выяснить как лучше. Вызовы local() или global() выглядят довольно нелепыми и сбивают с толку. К тому же совсем начинающие, как правило, не пользуются функциями. А когда назревает необходимость в функциях, то человек уже готов осознать концепцию локальных и глобальных переменных и вопросов особо не возникает.
Про отсутствие скобок это я тоже как пример привел. В принципе со скобками код понятнее, хотя без скобок иногда получаются более красивые, почти литературные выражения. По большому счету это не очень важно.
Про онлайн объявление функций можно еще подумать.
Мой первый вариант предполагал такое описание:
Code: Select all
myfunc(a,b,c) = {ret a+b*c}
Кстати от обычного объявления такое отличает только символ = и ключевое слово function. Вдруг я подумал, а нужно ли это ключевое слово?
Тогда может лучше так:
Code: Select all
myfunc = (a,b,c){ret a+b*c}
Отсюда возможен даже вариант с объявлением без присвоения кода:
Code: Select all
myfunc = (a,b,c)
anotherfunc(x,y,z) =
{
ret 25+x-y*z
}
myfunc(1,2,3) // вызовет ошибку
myfunc = anotherfunc
myfunc(1,2,3) // теперь правильно, фактически вызывается anotherfunc(1,2,3)
Re: Концепция Pixilang 3. Функции
аааааааааааааааааааааааааааа
вот все что могу прибавить
ну еще караул и прочее
безусловно видно 2 пути
либо язык - стартовый (наш ответ бейсику) для обучения и дальнейшего роста
либо - в большей степени самостоятельная вес4ь, пусть и не изотерический (фишка бледновата) и эскизно набросочный излишне (мощи и скорости не хватает)
при первом пути - задача заложить грамотную базу дальнейшего программирования на общепринятых языках
при втором - колбасим все что хотим, ориентируясь на свои запросы и ищем концепт идеи
вот
мой мо3г боюсь не осилит еще один синтаксис
вот все что могу прибавить
ну еще караул и прочее
безусловно видно 2 пути
либо язык - стартовый (наш ответ бейсику) для обучения и дальнейшего роста
либо - в большей степени самостоятельная вес4ь, пусть и не изотерический (фишка бледновата) и эскизно набросочный излишне (мощи и скорости не хватает)
при первом пути - задача заложить грамотную базу дальнейшего программирования на общепринятых языках
при втором - колбасим все что хотим, ориентируясь на свои запросы и ищем концепт идеи
вот
мой мо3г боюсь не осилит еще один синтаксис
Re: Концепция Pixilang 3. Функции
На мой взгляд идти первым путем не нужно... Ибо не программировать нужно учить, а логически мыслить
Итого - колбасим все что хотим!
Итого - колбасим все что хотим!
ВекторКодПиксельПолигон - ВотЧтоЯЛюблю!
Re: Концепция Pixilang 3. Функции
Товарищи, поконструктивней бы )
Может быть я в постах выше выражался заумными словами, так это термины в большей степени были предназначены для NightRadio. Ничего сложного там нет и все это полностью и на пальцах можно объяснить за 20 минут.
А запираться на текущем уровне бейсика/макро ассемблера, имхо не нужно. И никакого нового синтаксиса особенно не предвидится. Не нравятся функции - не используй вот и все Кстати говоря, для "академического" обучения, текущее состояние пикси не самое удачное. Для обучения пикси хорош в том плане, что получаешь не какие-то скучные текстовые данные в консоли, а прикольную графику, которую можно увидеть и "пощупать". Отдачу получить очень легко. Поэтому пикси интересен новичкам. Он довольно прост сам по себе, но не отражает некоторых канонических, "учебных" вещей. Например в пикси отсутствует явная типизация данных. Поэтому как первый шаг "в большой мир программирования" он не очень подходит, на мой взгляд. А вот задачу познакомить пользователя с программированием язык может, и его наглядность тут как нельзя кстати.
Вот мое видение пикси:
1. Основное назначение - всякие демки, мини трекеры, игры, рисовалки и т.п. (т.е. небольшие прикольные ЭКСПЕРИМЕНТАЛЬНЫЕ програмки)
2. Язык НЕ предназначен для создания какого-либо "профессионального enterprise" ПО
3. Язык может использоваться интересующимися для знакомства с программированием и "компьютерной логикой"
4. Язык НЕ СТОИТ использовать для "академического" обучения программирования (для этих целей есть тот же паскаль)
Т.о. пиксиланг - это язык для всяких арт проектов, цифровых художников, экспериментаторов и т.д. и т.п. А также просто интересная игрушка, в хорошем смысле этого слова, головоломка для интересующихся техникой и "цифровым" искусством.
Может быть я в постах выше выражался заумными словами, так это термины в большей степени были предназначены для NightRadio. Ничего сложного там нет и все это полностью и на пальцах можно объяснить за 20 минут.
А запираться на текущем уровне бейсика/макро ассемблера, имхо не нужно. И никакого нового синтаксиса особенно не предвидится. Не нравятся функции - не используй вот и все Кстати говоря, для "академического" обучения, текущее состояние пикси не самое удачное. Для обучения пикси хорош в том плане, что получаешь не какие-то скучные текстовые данные в консоли, а прикольную графику, которую можно увидеть и "пощупать". Отдачу получить очень легко. Поэтому пикси интересен новичкам. Он довольно прост сам по себе, но не отражает некоторых канонических, "учебных" вещей. Например в пикси отсутствует явная типизация данных. Поэтому как первый шаг "в большой мир программирования" он не очень подходит, на мой взгляд. А вот задачу познакомить пользователя с программированием язык может, и его наглядность тут как нельзя кстати.
Вот мое видение пикси:
1. Основное назначение - всякие демки, мини трекеры, игры, рисовалки и т.п. (т.е. небольшие прикольные ЭКСПЕРИМЕНТАЛЬНЫЕ програмки)
2. Язык НЕ предназначен для создания какого-либо "профессионального enterprise" ПО
3. Язык может использоваться интересующимися для знакомства с программированием и "компьютерной логикой"
4. Язык НЕ СТОИТ использовать для "академического" обучения программирования (для этих целей есть тот же паскаль)
Т.о. пиксиланг - это язык для всяких арт проектов, цифровых художников, экспериментаторов и т.д. и т.п. А также просто интересная игрушка, в хорошем смысле этого слова, головоломка для интересующихся техникой и "цифровым" искусством.
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Re: Концепция Pixilang 3. Функции
С назначением языка почти согласен...
Теперь про функции. Что-то пока не особо все склеивается. У меня уже появился аварийный вариант - забить на параметры и локальные переменные, не усложняя язык :)
А если не забивать, то получается вот что..
Предложенный способ, когда по умолчанию все переменные вне функции - глобальные, а внутри - локальные, подходит к структурированным языкам, типа Си. В них мы точно знаем и четко видим, в каком месте определена глобальная переменная, в каком - локальная.
В Пикси увидеть место первого определения переменной - это уже проблематично. Особенно, если я хочу заюзать локальную переменную с тем же именем, что и глобальная.
Теперь смотрим далее. Если мы определяем параметры функции в скобках myfunc( x, y, z ), то у пользователя функции появляется возможность передавать не все три параметра, а, например, только два - это упростит использования языка и защитит от всяких косяков со стеком. Но если, пользователь передал только два параметра, вместо трех, то функция может использовать третий параметр в роли временной локальной переменной. Да и вообще любой параметр приравнивается локальной переменной. Значит я могу написать объявление функции вот так:
Это мое очередное предложение. Жду комментариев :)
Теперь про функции. Что-то пока не особо все склеивается. У меня уже появился аварийный вариант - забить на параметры и локальные переменные, не усложняя язык :)
А если не забивать, то получается вот что..
Предложенный способ, когда по умолчанию все переменные вне функции - глобальные, а внутри - локальные, подходит к структурированным языкам, типа Си. В них мы точно знаем и четко видим, в каком месте определена глобальная переменная, в каком - локальная.
В Пикси увидеть место первого определения переменной - это уже проблематично. Особенно, если я хочу заюзать локальную переменную с тем же именем, что и глобальная.
Теперь смотрим далее. Если мы определяем параметры функции в скобках myfunc( x, y, z ), то у пользователя функции появляется возможность передавать не все три параметра, а, например, только два - это упростит использования языка и защитит от всяких косяков со стеком. Но если, пользователь передал только два параметра, вместо трех, то функция может использовать третий параметр в роли временной локальной переменной. Да и вообще любой параметр приравнивается локальной переменной. Значит я могу написать объявление функции вот так:
Code: Select all
function myfunc( par1, par2, local_var1, local_var2 )
{
//тут я принимаю значения из параметров par1/2 и юзаю переменные local_var1/2 как локальные, т.к. они явно заданы выше.
}
Re: Концепция Pixilang 3. Функции
Не сразу, но я понял о чем ты говоришь. Надо подумать.NightRadio wrote: Предложенный способ, когда по умолчанию все переменные вне функции - глобальные, а внутри - локальные, подходит к структурированным языкам, типа Си. В них мы точно знаем и четко видим, в каком месте определена глобальная переменная, в каком - локальная.
В Пикси увидеть место первого определения переменной - это уже проблематично. Особенно, если я хочу заюзать локальную переменную с тем же именем, что и глобальная.
Иллюстрация проблем:
Code: Select all
x = gpx // получаем координаты указателя
y = gpy
color = #ff3377
function draw_sprite(x, y) // Неопределенность: Что будет с именами этих параметров (x,y) и одноименными глобальными переменными?
{
color = #778899 // Неоднозначность: Внимание! Преопределяем глобальную переменную.
// Проблема: Мы не можем определить локальную переменную с именем color
}
Но скрещивать параметры и локальные переменные неправильно логически. В общую кучу попадают две разные по смыслу сущности. Если в функции мне нужно будет штук 10-20 переменных, но в качестве параметров используется только 2 штуки. Выглядеть это будет монстрообразно. Лучше уж как ты раньше предлагал с local(...) или как в паскале сделано, завести отдельную область для переменных:
Code: Select all
global_var = 12
function f(param1, param2): // Переменные объявляются после : и до {
// Начинается область определения переменных
a=5
b=a
c = global_var // присваиваем локальной переменной с значение глобальной
{
// code
x = 5 // Тогда эта строка должна вызывать ошибку
}
Если в коде мы в любом месте можем переменные объявить, то в функции - нет.
Ведь что такое функция? Это маленькая программа, использующаяся в основной программе.
И у нее есть свои переменные. И внутри функция должна быть подобна основной программе.
Концепция локальных переменных, объявляемых в любом месте функции, как мне кажется, полностью соответствует назначению функций.
Надо подумать как лучше всего решить эти проблемы.
Добавил чуть позже:
В принципе есть несколько путей решения этого конфликта:
1. Ввести специальное ключевое слово для объявления переменны (например так: var x=10)
2. Ввести специальный синтаксис для локальных переменных
Code: Select all
:x = 18
.y = 16
Наверное самый удачный способ это использовать точку в начале имени переменной:
Code: Select all
x=15
y=16
z=25
function f(x,y)
{
.v = -1 // объявляем и используем локальную переменную .v
.t = x+y // присваиваем локальной переменной сумму параметров
z - 10 // уменьшаем на 10 глобальную переменную z
}
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Re: Концепция Pixilang 3. Функции
Вариант с var кажется наиболее уместным. Под него проще заточить компилятор и код выглядит более-менее структурированным.
Вот только всё это начинает напоминать мне Си :( Пока не пойму, хорошо это или плохо
Code: Select all
function myfunc( x, y )
{
var a,b,c
}
Re: Концепция Pixilang 3. Функции
Hi? to all! Мне кажется, как вариант - все переменные, объявленные вне функций считать глобальными. Объявленные в теле функций- локальными, изменение глобальных переменных в теле функций- запретить. Таким образом и обратная совместимость с уже написанными прогами и демками останется. А получение и передача параметров из функции и в функцию - не суть важно (чем больше значений возможно будет передать- тем, имхо, будет лучше). Мне кажется, если выложить пару подробных примеров использования функций с новой версией Пикси, то и начинающие все поймут
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Re: Концепция Pixilang 3. Функции
Такой метод довольно любопытный. Его плюс в том, что у кода получается довольно четкая структура - кто с кем связан. Но недостатков, увы, больше: довольно часто приходится использовать набор глобальных переменных, например, размер экрана, частота дискретизации и т.д.. Если их каждый раз передавать в параметрах - это будет не удобно и добавит лишние тормоза.
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Re: Концепция Pixilang 3. Функции
Вообщем, определенность в данном вопросе до сих пор не достигнута, а я начинаю склоняться к тому, чтобы вообще не усложнять язык функциями и локальными переменными :) Поэтому в начале темы я добавил небольшой опрос. Прошу всех заинтересованных проголосовать.
Re: Концепция Pixilang 3. Функции
Поз-моему последний вариант равнозначен отсутствию пиксиланг 3.
Я за фукции с локальными переменными.
Причем считаю что лучше всего отделить локальные переменные специальным синтаксисом типа точки, или другого символа перед именем переменной.
Как я писал выше...
Я за фукции с локальными переменными.
Причем считаю что лучше всего отделить локальные переменные специальным синтаксисом типа точки, или другого символа перед именем переменной.
Как я писал выше...
Re: Концепция Pixilang 3. Функции
я за подпроект - минимализм полный но на базе наработок pixi и "полноценная версия" сохраниться и упрощенческий вариант будет