LINUX.ORG.RU

\[палёный мёд\] фантазии на тему своего ЯП

 , , ,


0

4

Привет, котаны!

Я решился на отчаянный шаг — поэкспериментировать с компиляторами. После долгого сидения я понял что питон это не то — надо шагнуть дальше. Ну, хотя бы в с т.з. функционального программирования. Сразу скажу что концепции я пока не вижу и ответов на фундаментальные вопросы типа степень ленивости языка, всякие там монады, в каком виде делать ООП (и делать ли?) у меня нет. Но всё же забавно поиграться просто с синтаксисом.

Основные приоритеты: компактность, наглядность, удобное представление рутинных действий. Цели: высокоуровневое системное программирование. Т.е. целей писать на нём ядро нет, вопросы скорости пока не интересует. Скажем, хотелось бы ЯП чтобы можно было легко писать как скрипты аля-шелл, так и полноценные программы. Но внутренние детали я бы хотел обсудить позже, и так вопросов куча. Вот что родилось в моём больном воображении:

/* DATA TYPES */
//ints and floats, types are infered from the value
i = 1; f = 1.0
// list
l = [1,2,3]
//tuple (arguments of functions are passed in tuples)
t = 1, 2, 3
//tuple with named fields
tuple X: a, b, c
x = X a=1, b=2, c=3
// the same but with optional parens
x = X(a=1, b=2, c=3)
// access tuple attrs
print x.a, x.b, x.c
//hashes
{}  // empty hash
h = {b=>2,a=>1}
print h.keys // -> "pb, a]" because hashes preserve insert order

//regular expressions
pattern = /[A-z][a-z]{1-2}/


/* BASICS */
// define variable
x = 1

// define function "z" of two args
z x:int, y:int = 2*x + y

// function invocation
z 1, 2
// or
z x=1, y=2

// composition, equivalent of print(z(1,2))
print z 1, 2

// conditions:
if a > 2:
  pass
//if-else in one line
if x == 2: {x = 3} else: {x = 4}
//regexp
if x ~= //


switch x:
  x == 1: pass
  x < 10: print("x is really less than 10")
          continue  # go down
  x < 5 : print("x ")
  _     : print("what a strange X")


/* SUGAR */

# shell invocation
x = `ps ax | wc -l`


# equivalent of vm = VM(); ...; vm.stop()
vm1 = VM(), vm2 = VM():
  on cleanup:
    vm1.stop and vm2.stop():
  ...


/* HIGHER ORDER FUNCTIONS */
# a(b(c))
c | b | a
a . b . c

/* GROUPING */
// block may appear at any place where expression is acceptable.
// the return value is the last statement
// statements are separated by semicolon.
x = true
if x: {print "it turned out that x is true"; x=false}
else: {print "x is false, sad but true"; }


/* HELLO, WORLD */
main argv =
  print "hello, hell"
  print "my args:", argv

/* STRING SUBSTITUTION */
x = 666
print "x is equal to ${x+1}" // equivalent of { tmp = x+1; printf("x is equal to %d\n", tmp) }

/* EXCEPTIONS */
// catch exception and get its value in _err
fd = open "filename" || die "exception ${_err}"

try:
  fd = open "filename"
except NotFound:

fd = try {open "filename"} except NotFound: -1


/* LANGUAGE MODES */
//shell invocation in backticks
files = `ls -la /tmp`
`for f in ${files}; do scp $f remote:/tmp; done` \
  || die "scp failed with ${_err}"


/* COMMENTS */
// this is a comment
# and this is a comment
/* and this as well */
; have fun with many comment styles


/* SMALL THINGS */
for elem in some_list:
  ...
print elem  //will raise error because loop variables are not seen outside the loop by default

// for this reason file will be automaticaly closed once the control reach the end of the loop
for l in os.open("some_file"):
  ...

PS кодовое название — velosipedix. PPS case ymn, archimag, baverman, tailgunner, qnikst, mv и всех других кого забыл :)

PPPS похоже что инета у меня не будет до воскресенья...

★★★★★

Последнее исправление: CYB3R (всего исправлений: 2)
Ответ на: комментарий от fragmentor

А чего ты хотел? Если бы такой язык можно было написать, означало бы, что приблизилсь к ИИ настолько, что добрая половина человечества была бы не нужна (точнее в их текущих задачах). В этом случае боязнь с вашей строны должна скорее быть «рефлексивна».

anonymous
()
Ответ на: комментарий от anonymous

Если бы такой язык можно было написать, означало бы, что приблизилсь к ИИ

Не означало бы. Я же не говорю, что язык должен переваривать конструкции типа «I want a cool program for music playing». Я имею в виду, что у ЯП должен быть человекоориентированный синтаксис. Посмотри на тот же bash, или хотя бы python, а потом глянь на С. Если на первом умственно полноценный человек уже спустя пять-десять минут может написать средней сложности скрипт, то при виде С любой не нерд начнёт зевать и депрессировать. Ёпт, времена ассемблероподобного трэша должны были остаться во второй половине двадцатого века вместе с магнитными лентами и бородатыми красноглазыми чепушилами. В нашем веке умение писать программы должно быть приравнено к банальной грамотности, как умение читать и писать на родном языке, а как научишь людей писать проги на этих кибернетических блевках типа С или С++? Разве что делать повальную лоботомию, для усидчивости, лол.

fragmentor
()
Ответ на: комментарий от geekless

Ты прямо ответил на мой вопрос что я хочу получить. К сожалению, я пока не могу описывать свои желания так чтобы они были понятны тем кто в этом разбирается.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Да, я, в принципе, сейчас могу озвучить то что мной движет:

Написание управляющего софта для кластера. (just for fun конечно же). Отсюда и требования по регекспам и вызову шелл-функций: это нужно для вызова всякого системного софта от mdadm и megacli). Ну и, конечно, встроенные event loop и гринлеты, куда без них.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от fragmentor

Я имею в виду, что у ЯП должен быть человекоориентированный синтаксис

python

Ну и в чем проблема использовать сей язык? Или тоже недостаточно? В любом случае, все задачи подобный подход не покроет, хотя может по-вашему софт для атомного реактора пусть пишет «банально грамотный».

anonymous
()
Ответ на: комментарий от true_admin

И для этого ты хочешь сделать _язык_? Не чекер для чего-то в духе pylint, не макросистему, не DSL, а прям-таки язык общего назначения?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Ну и в чем проблема использовать сей язык?

В том, что даже его синтаксис далёк от такового у естественных языков.

fragmentor
()
Ответ на: комментарий от anonymous

Вот также интересная (в контексте edsl) заметка

спасибо, то что нужно.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

И для этого ты хочешь сделать _язык_?

Ты уже спрашивал. Питон мне своей закостенелостью надоел, хотя я продолжаю его активно использовать.

не DSL

Наверно, я хочу DSL. Я извеняюсь за неточность формулировок, почему-то я смотрю на мир другими глазами.

Вот если я скажу что мне нравится то как в хаскеле вводятся новые операторы и комбинируются функции, мне нравятся встроенные регекспы перла и мне нравится подходит питона «сделаем синтаксис простым и читабельным» это облегчит понимание того что у меня в голове?

true_admin ★★★★★
() автор топика
Ответ на: комментарий от true_admin

это облегчит понимание того что у меня в голове?

Да это и так было понятно. Малоприятная субстанция.

anonymous
()
Ответ на: комментарий от vertexua

Для управления кластером?

Да, почему нет? Под управлением я понимаю запуск нужных команд (в основном запуск виртуалок и запуск чего-то внутри виртуалок) и периодическое снятие различной статистики системой мониторинга. Гринлеты отлично подходят для этого, имхо.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Питон мне своей закостенелостью

И это мешает тебе взять его за прототип?

надоел

Ну, против этого не попрешь.

как в хаскеле вводятся новые операторы и комбинируются функции, мне нравятся встроенные регекспы перла и мне нравится подходит питона «сделаем синтаксис простым и читабельным»

Первое опирается на мощную систему типов, а встроенные регэкспы и шелл вообще не требуют доработки синтаксиса и реализуются препроцессором:

userlist = sh("cat /etc/passwd | awk -F: '{print $1;}')
fusers = [u for u in userlist if u.matches("[Ff].*")]

Всего-то реализовать абстрактный интерпретатор шелла (функция sh) и регэкспов (matches) %) (если тебя интересует статический контроль).

это облегчит понимание того что у меня в голове?

Не очень, но тут главное, чтобы ты сам понимал решаемую задачу. Пока же со стороны это выглядит классикой: «Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмина, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича  — я бы тогда тотчас же решилась» (ц)

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)

Лень читать полностью, но, кажется, вам стоит посмотреть на Pure.

buddhist ★★★★★
()

Основные приоритеты: компактность, наглядность, удобное представление рутинных действий. Цели: высокоуровневое системное программирование

Изобретаешь perl?

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

После упоминания в треде ruby

В контексте желаний ТСа упоминать руби можно только с иронией... Вот перл - это серьезно.

no-such-file ★★★★★
()
Ответ на: комментарий от baverman

Только бывшими похапешниками.

как раз в джанге есть костыли на эту тему потому что, например, __dict__ не имеет порядка и в моделях с этим приходится бороться. Так что в веб-разработке это нужно. Вопрос оверхеда в таких случаях не стоит.

//ТАВИМ

anonymous
()
Ответ на: комментарий от tailgunner

Первое опирается на мощную систему типов

в чём измеряется мощность? Ну, в любом случае, я не против того чтобы подсказать компилеру типы если это сильно упростит компилер.

//ТАВИМ

anonymous
()
Ответ на: комментарий от anonymous

как раз в джанге есть костыли на эту тему потому что, например, __dict__ не имеет порядка

Списки в пухтоне уже отменили?

geekless ★★
()
Ответ на: комментарий от anonymous

Так что в веб-разработке это изредка нужно.

Во имя луны.

baverman ★★★
()
Ответ на: комментарий от fragmentor

Я одно время думал над objc-style синтаксисом, только не для вызова методов [object doSomethingWithX:x andY:y], а для функций вообще, например [print («Hello, world!») to (stdout)] ну или как-то так, легко можно по-русски и по-какому-хочешь через gettext и позиционные параметры как у printf (вообще давно пора i18n всех языков, программы же испольуют language pack'и, и код разумеется надо не как текст, а как структуру; completion все равно это делает, но гоняет буквы туда-сюда как идиот). Параметры не вручную писать, а задавать как outlets, типа как в Xcode тянешь outlet на control, они и соединились. И получается, что кроме двух состояний: сорец и рантайм, есть еще промежуточное «template», по типу xib. Его можно инстанциировать, и оно само начинает работать, не надо конструкторов и прочей лабуды по управлению ресурсами. Такие же аналогии провелись и для вызовов функций — кроме собственно кода и activation record всегда есть промежуточное состояние with bound arguments, не путать с closures, я щас уже подзабыл суть идеи, да и времени не найду ее реализовывать. Основа такая: чтобы вручную не клеить контроллеры, во время дизайна биндишь аргументы функций/методов на что угодно, и получаешь автоматические сработки этих функций в нужных местах, reactive programming. И контроллер как бы растворяется в шаблоне.

В принципе похожая вещь была в редакторе карт первого старика, только там везде примитивные значения.

arturpub ★★
()
Ответ на: комментарий от arturpub

Визуально похожая, естественно, не идеологически.

arturpub ★★
()
Ответ на: комментарий от anonymous

я не против того чтобы подсказать компилеру типы если это сильно упростит компилер

И вместо простых комбинаторов ф-ий с ограничениями по классу типов получить бойлерплейт: (func1 :: Type1) `op` (func :: Type2)?

anonymous
()
Ответ на: комментарий от geekless

Списки в пухтоне уже отменили?

вот у тебя такая модель:

class MyModel(Model):
  id = Unique()
  name = String()
  .. 

Вот вопрос: как сделать так чтобы поля не скакали в базе? Т.е. чтобы всегда в базе сначала шёл id, потом name. В джанге тупо счётчиком пользуются. Подменить __dict__ на инстанс OrderedDict низзя, оно прибито.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Я просто трезво оцениваю свои силы. Естественно мне бы хотелось вывод типов и ещё много чего.

Я пока забил на всё это дело, надо осмыслить вышесказанное.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от true_admin

O_O

Вот вопрос: как сделать так чтобы поля не скакали в базе? Т.е. чтобы всегда в базе сначала шёл id, потом name. В джанге тупо счётчиком пользуются. Подменить __dict__ на инстанс OrderedDict низзя, оно прибито.

У меня аж что-то глаз задергался. Не разрывай к хренам мои остатки веры в человечество: скажи, что я тебя неправильно понял.

geekless ★★
()
Ответ на: O_O от geekless

У меня вот ничего не дергается, наверное я слишком анскилен. Тем не менее редко-редко порядок ключей если не требуется, то, как минимум, удобен, и часто-часто в этих случаях его не хватает и *ничего* не сделать (кроме уродской попутной передачи массива с порядком).

arturpub ★★
()
Ответ на: комментарий от fragmentor

Слабо создать язык программирования, не отличающийся от какого-нибудь естественного? Английского, например. Или боитесь, что вам на хлеб нечем зарабатывать будет?

Жжош красава.

Over the years, many systems have claimed to have a natural-language. or English-like, syntax to allow use by non- programmers (this has included COBOL and SQL, now undoubtedly considered as non- end-user programming languages) predicated on the assumption that mere end-users cannot handle structured or formal languages. (C) сам знаешь чей

auto12884839
()
Ответ на: комментарий от fragmentor

Я имею в виду, что у ЯП должен быть человекоориентированный синтаксис.

Зачем это? Чтобы полчища быдлокодиров, ниасиливших ничего кроме синтаксиса жабки были обильно пополнены полномасштабными 100% ниасиляторами?

auto12884839
()
Ответ на: комментарий от geekless

Потому что ФП и ИП — это два подхода к описанию алгоритов, которые появляются, когда мы по-разному отвечаем для себя на вопросы, что вообще такое алгоритмы, и какие их свойства нам важны.

Нормальный ФП вообще не должен быть алгоритмическим вообще-то.

auto12884839
()

Вот что родилось в моём больном воображении:

Ну и чем твой ЯП отличается от более чем 2к существующих на настоящий момент? Где свежие идеи, новые концепции, оригинальный дизайн? Общеупотребимые операторы присвоения и цикла, тщательно изуродованные под воздействием NIH syndrome? Ты уныл, анон. Тред и удалённые не читал.

auto12884839
()
Ответ на: комментарий от cdshines

Потому что все гомоиконные языки уже сделали: лисп, форт, машкод. Других быть не может.

anonymous
()
Ответ на: комментарий от fragmentor

И зачем будет нужен такой язык, если даже брейнфак удобнее?

anonymous
()
Ответ на: комментарий от true_admin

немного осмыслил?

я тебе ненавязчиво подсказывал, а другие так вообще открытым текстом, что свой язык надо делать на базе существующего

еще вкратце:

1. по статической типизации ты не можешь выдать портянку «вот мне не нравится то и то, и не хватает этого и вот этого» (читать тапл для выдачи такой портянки не обязательно)

2. ты в требованиях не написал «скорость работы с++»

вывод:

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

еще тебе будет нужна стандартная библиотека

в общем вывод — чтобы у тебя был язык более-менее приличный, тебе можно прикрутить свой синтаксис к питону

взгляни на boost::python, хотя для начала можно реализовывать все на самом питоне

впрочем, *лично* я на *твой* синтаксис смотрю совсем без энтузиазма (за исключением отдельных положительных моментов, типа ловли исключения)

*но* если ты сделаешь удобный способ прикручивать *чужой* синтаксис к питону (т.е. скажем у меня есть на коленке сделанный парсер, и я его могу легко к твоему изделию прикрутить), а также *чужой* тайпчек и вывод типов, то это вполне возможно будет интересно, причем, подозреваю, что не только мне (если конечно это до сих пор не сделали — я не в курсе)

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от www_linux_org_ru

Я переключился на изучение хаскеля и стал гораздо лучше понимать как устроен этот мир. Меня он сильно впечатляет, но я пока не понимаю на что он годится в реальной жизни. В связи с прозрением свой ЯП стало делать не интересно.

Что касается тайпчекера то вряд ли я его осилю без аннотации всех типов всех переменных. А такое «замусоривание» кода никому не нужно. Я одним взглядом читал http://morepypy.blogspot.com/2012/01/comparing-partial-evaluation-and.html итд из этого блога, ну нахрен такое счастье :). Да и в одиночку пилить никакого желания нет.

можно прикрутить свой синтаксис к питону

Пока самая здравая из мыслей что меня посещали :). Уж раскрытие строк (string expansion) сделать можно. Собстно, я уже делал с помощью inspect и какой-то матери, но код с inspect до добра не доводёт, поэтому в коде я такое не использую.

Можно собраться (виртуально) и обсудить чего не хватает питону для полного счастья. Я бы, например, заменил часть методов на операторы. Ну вот что за нахрен list.append(), имхо, list << elem было бы гораздо нагляднее. Впрочем list += [elem] тоже неплохо (и уже есть). (да, я любитель хорошего синтаксиса и не поддерживаю хвостового стрелка в том что синтаксис не важен. Для меня синтаксис, семантика и эстетическое удовольствие тесно связаны).

true_admin ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Что касается тайпчекера то вряд ли я его осилю без аннотации всех типов всех переменных. А такое «замусоривание» кода никому не нужно.

facepalm

я же говорил целый абзац про опциональную типизацию (что в переводе может означать, что ты даешь возможность другим пробежаться по твоему ast и почитать-пописать туда свою опциональную инфу)

но если тебе это не нужно — не делай, никто не заставляет — мне интересен даже просто resyntaxed python

Можно собраться (виртуально) и обсудить чего не хватает питону для полного счастья. Я бы, например, заменил часть методов на операторы. Ну вот что за нахрен list.append(), имхо, list << elem было бы гораздо нагляднее.

тут от меня помощи не жди, т.к. я питон практически не знаю (с точки зрения *твоих* задач) — но краткая выжимка по улучшению питоньего синтаксиса мне интересна

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от true_admin

Ну вот что за нахрен list.append(),

я имел в виду, что не жди от меня подобной критики питона — я его слишком мало знаю

кое-что сказать про потребности синтаксиса я могу, но учти, что у меня они могут быть довольно специфичные — скажем, дроби, верхние-нижние индексы и т.п.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

про опциональную типизацию

Ты про аннотацию или про что? Я же говорил что есть два простых подхода: делать явную строгую типизацию, либо не делать её вообще. Частичное решение выглядит чужеродно, я пробовал на своём коде.

ты даешь возможность другим пробежаться по твоему ast

Кому другим-то? И для чего?

краткая выжимка по улучшению питоньего синтаксиса мне интересна

Да ничего нового не скажу. Например, заменить тернорный оператор на сишный аналог для компактности (про то что ":" уже занято я знаю, тут придётся пожертвовать контекстно-свободной грамматикой).

Есть много спорных идей. Они плохо ложаться на синтаксис питона. Именно поэтому я в итоге попытался отойти от питона вообще. Попытка провалилась.

true_admin ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

кое-что сказать про потребности синтаксиса я могу

говори, интересно посмотреть на новые синтаксические конструкции. Желательно с описанием их предназначения. С дробями понятно (кстати, как выглядят?), индексы для чего?

true_admin ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Частичное решение выглядит чужеродно, я пробовал на своём коде.

/me пожал плечами

хозяин — барин, хотя по-моему зря

Да ничего нового не скажу.

я, собственно, и не предполагал, что ты *сейчас* скажешь — но постепенно какие-то ништяки в синтаксисе у тебя будут появляться, и это мне интересно

www_linux_org_ru ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.