stdlib.md

megj. a dupla egyenlőség jel nem lesz része a nyelvnek csupán a funkciók működésének szemléltetésére használatos

arithmetic functions:

sum(1 2 3) == 6
sub(5 2 1) == 5-3-1 == 1
div(8 2 2) == 8/2/2 = 2
prod(2 3 4) == 2*3*4 == 24
mod(9 3 2) == 8%5%2 == 1
min(8 3 7 2) == 2
max(8 3 7 2) == 8

comparisons: (ezeknek a nevével még mindig nem vagyok teljesen elégedett, de azért jobb)

equal(2 sum(1 1)) == true
less(2 3) == true
greater(2 3) == false
... további változatok a not függvény segítségével érhetők el. pl: lessorequal == not(grater(2 3))

lists and strings:

range(5) == [0, 1, 2, 3, 4] == x
len(x) == 5
get(x 2) == 2
get(x 2 3) == [2, 3]
rev(x) == [5, 4, 3, 2, 1, 0]
merge(x range(2)) == [0, 1, 2, 3, 4, 0, 1]
merge(x range(2) 2) == [0, 1, 0, 1, 2, 3, 4]
remove(x 1) == [0, 2, 3, 4]
remove(x 2 4) == [0, 1]

logical:

not(true) == false
any(false true false) == true
all(true true false) == false

general: (még mindig hajlok picit a log felé)

print("asd")

functional:

map(sum(1) range(3)) == [1, 2, 3] // ez kicsit káoszos, de megszokható: a map az odarakja paraméternek minden elemet külön külön az első függvénynek
filtertrue(equal(2) range(3)) == 2

• arithemtic functions: kiri!
• comparisons: kiri!
• többelemű adattípusok: szerintem ne mutálják a funkciók, hanem újat adjanak vissza, ne legyen none a visszatérés
• logical: kiri!
• print: mindenféleképp jobb a log, mint a print, mivel hasznos előzményt menteni timestamp-pel, illetve egyéb infóval (pl. mi printelt)
• functional: amit csinálsz, azt lambdával szokták, valóban zavaros úgy. tehát valahogy így:
  (filtertrue (lambda x (greater x 1)) [1, 2, 3]) == [2, 3])
  amúgy ok
• comprehensionök:
  vizuális / kártyás megjelenítést így képzelem: megadsz egy listát, automatikusan mutatja, hogy milyen elemeket ad vissza
  ha listád van kételemű tuple-ökről, akkor azonnal kiírná, hogy egy körben ezeket kapod
  a tuple elemei lehetnének nevesítettek (akár kötelezően (?)) és akkor a for loopodon belül azonnal használhatod ezeket a neveket
  ha mapping elemeit rakod for-ba, akkor kapsz egy (key, value) tuple-t, amit használhatsz ezekkel a nevekkel, de adhatnál nekik aliast és mellette megjelenne, hogy : key, : value a kártya tetején a forrás iterable alatt
  lenne egy filter mező, mint a comprehension syntax if része: (func(x) for x in list if predicate(x))
  az alapvető feldolgozás map lenne, tehát lenne egy funkció mező is
  akár "break" mező is lehet, ami ugyancsak egy vizsgálat: ha igaz, akkor nem ad vissza több elemet
• loopok: egyelőre nem tudom, hogy lenne barátságos ÉS konzisztens
• számok: valószínűleg az 1.0 jelölés működne floatokhoz és amúgy ja, ne fárasszuk, de az implementáció elrejtése ne vezessen arra, hogy a felhasználónak ismernie kelljen az implementációt, hogy jól tudja használani D;
• dict: tulképp egy hashmap, tehát a kulcsok hashable (immutable) értékek lehetnek. a neve akár "mapping" is lehet. kezdő / hobbi programozóknak szánva egy list-dict hibrid érdekes lehet, ahol van index és key elérés (index hozzáadás sorrendje alapján, opcionális key, ha megadsz)

• bools: szerintem legyen true és false az egyszerűség kedvéért
• függvény: az fnc és function is jó, szerintem a func is jó, a fun is elég fun
• import: ok, egyelőre nem kell, de később mindenféleképpen
• scope: a func paramétereinek a funkció törzse a scopeja, amit rootba írsz az meg legyen "global" egyelőre. tehát valami scope priority, ahol a legközelebbi scope-ban lefoglalt név élvez prioritást
• conditional: scheme-style "cond", "if", illetve kéne egy switch is
• comments: nekem a py miatt reflexből a # jön és php-ban is működik. py-ban """multiline comment""", phpban /* multi */, de ezekkel az a baj, hogy ha olyan részt kommentelsz, amiben már van multiline comment, akkor a belső komment-záró lezárja a külsőt :D mivel a text sourcet végül úgyis a frontendünk fogja generálni, így nem biztos, hogy kell multiline comment. a ; jó, mert lisp-szerű lesz a pseudo, de a # és / (vagy //) ismerősebb lehet több programozónak. mindenféleképpen olyan kéne, amit nem használunk másra és akkor ízi az inline commentelés parsingje is
• minusz: scheme-ben (- 10) a szintaxis, de szerintem jobb, ahogy te írtad (tehát egyben)
• elemek elérése / slicing: az érdekes, hogy a lista "function" is, de szerintem egyben átemelhetnénk a python-féle [start: end:step] slicing szintaxist, mert igen egyszerű. ugye ott end-1 az utolsó elem, amit visszaad, tehát a start és end különbsége egyenlő a visszaadott elemek számával, ha step==1
  elérés: list[x] és pl list[-1] == utolsó elem

egyebek

• funkció paraméterei: most csak pozíció alapú elérésről volt szó, de ha lesznek olyanok, amiknek default paramétere van, akkor kéne nevesített paraméter megadás is, hogy ne kelljen minden előző defaultozott paramot is megadni, ha pl az utolsó paramétert akarjuk csak felülírni. itt úgy kéne, hogy elöl lennének, amiknek nincs defaultjuk. ez az unpacking-hez is hasznos, tehát dictet unpackelhetsz funkciónak, ahol a kulcsok a paraméterek nevei
• lambda: szerintem ez a név sokakat megzavar, helyette lehetne anon. pl: (map (anon x (+ x 1)) [0 1 2]) -> [1 2 3]

• kommenteknél szerintem mindképpen egy karakteres legyen, mert feleslegesen verbose pl a /* főleg úgy hogy ennyi szabad karakterünk van. A / és a ; azért tetszik jobban mint a # mert "visszafogottabbak" tehát kevésbé vonják el a figyelmedet, de ehhez nem ragaszkodom túlságosan, csak az egykarakteres megoldáshoz
• bools, scope, import: ok
• függvénynév: az eddigiek mellé pedobnám a rust-os fn-t is
• conditional: én azt szeretném hogy egy féle képpen de mégis effektíven lehessen mindhárom formát megvalósítani és ne legyen több lehetőség
• default paraméterek eszembe se jutottak eddig, de tényleg fontos kitalálni rá valamit
• a lambda szó tényleg megzavaró, tehát a helyettesítését támogatom

https://docs.python.org/3/reference/grammar.html