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

functional kiegészítés:

• map (fn, *iters) -> iter
  vesz mindegyikből egy elemet és a fn-nek adja paraméterként, tehát: fn( iter1[0], iter2[0] ), fn( iter1[1], iter2[1] ), ...
• reduce (fn, iter) -> val
  pl: reduce( sum, [1, 2, 3, 4, 5]) == ((((1+2)+3)+4)+5)
• zip (*iters) -> list[tuple]
  párhuzamosan vesz mindegyik iterből egy elemet és visszaadja őket tuple-ként, pl: zip ([1, 2, 3], [5, 4, 3, 2]) == [(1, 5), (2, 4), (3, 3)]
  (legrövidebb végénél megáll)
• filter (fn, iter) -> iter
  azokat az elemeket adja vissza, amikre igaz a callable (lehet fordított működésű "filterfalse" is)

operátorok:

• floordiv (a, b)
  maradéktalan osztás, ami megegyezik ezzel: floor(div(a, b))
• divmod (a, b)
  maradéktalan osztás + maradék tuple: (floordiv(a, b), mod(a, b))
• any (iter) -> bool
  igaz, ha bármely elem igaz (ha üres, hamis)
• all (iter) -> bool
  igaz, ha minden elem igaz (ha üres, igaz: minden zöldésget megettem a tányérról!!4! igaz, nem volt rajta zöldség)

-a reduce nem biztos, hogy kell, mert eleve olyan függvények kellenének, amik így működnek több elemre

• tuple lehet hogy elég lenne később, mert ott nem csak függvényt kell implementálni hanem típust
• a filterek működése csomó mindenkit megtéveszt szóval lehetne eleve olyan neve ami implikálja hogy az igazakat szedi ki (pl filtertrue)
• akkor az and helyett lehetne az all és az or helyett az any

merge-elem a két listát és felrakom a repo-ba

szintaxis:

• a funkció deklaráció lehetne lamdaszerű, pl. divmod = func (a, b) : tuple(floordiv(a, b), mod(a, b))
• egy sor a szöveges változatban megfelelhetne egy parent kártyának a vizuális változatban
  a loopok / if szintaxison még el kell gondolkodni, illetve egyáltalán kellenek-e?! ki kell próbálni nélkülük

típusok:

• a var kulcsszó nem feltétlenül kell, kivéve ha ezzel jelölnénk, hogy mutable
• a num talán túl általános, sok funkció működik csak inttel, tehát legalább egy int/float szétválasztás kéne
• a tuple igazából megegyezik a listtel (persze attól is függ, hogy hogyan implementáljuk), csak immutable
• a listnél lehetne index elérés, de később mindenféleképpen kell (ordered)dict is. megfontolandó: phpban az array egyszerre list és dict, tehát rendezett (indexelt), de key-hez kötötten is lehet bele pakolni elemeket. talán mi is csinálhatnánk így
• set sem ártana, sok feladatot leegyszerűsít
  pl pythonban:
  egy elemmel: if item in set; if item in dict.keys()); if 'b' in 'blabla';
  több elemmel: if set(1, 2) in set(1, 2, 3); if 'bla' in 'blabla'

felület:

• a keret / indent megfelelne egy szintnek, tehát egy zárójel-csoportnak
• az egy szinten lévő elemek közötti margin megegyező (pl. egy funkció paraméterei), de a szintváltásnál nagyobb kell (így azonnal tiszta)
• színek: pl indent szintenként más színű (bal) keret, néhány reddit kliensben van ilyen
• programonként kell egy felület, ahol megadhatod a konfigurációt, pl. a program tetején

etc:

• az all(and, or) cseréjének egyelőre nem látom hátulütőjét (haha)
• minél explicitebb nevek kellenek, tehát támogatom a "filtertrue"-t
  pl. a comparison funkciók neve szerintem nem elég egyértelmű
• ha sikerül megegyeznünk egy standard funkciókönyvtárban, elkezdhetnénk implementálni őket Pheudoban
• a funkciók nevéhez felhasználhatnánk más prognyelvek példáját: népszerűség alapján súlyozva a meglévő nyelvek funkcióneveit az adott feladatra
• fontos kérdés: az "api" legyen egyszerű, vagy az implementáció?

Loopok:

Két érvem is van a loopok megtartása mellett:

• list comprehension szintaxisában jól használhatóak (nekem pl jobban tetszik a python list comprehension, mint a haskell)
• az embereknek az agya eléggé rá van már állva a használatára és jóval kevesebb gondolkodást jelent így mint egy rekurzió, tehát annak ellenére, hogy támogatom az azonos funkcionalitású elemek összevonását, ezt meghagynám, hogy minden 'newcomer'-nek könnyebb dolga legyen, mert a haskellnél jóval barátságosabb nyelvet szeretnék

Változó deklaráció

Kulcsszó mindenképp kell. Ha belegondolsz pythonban is van, csak ott infix (az egyenlőségjel). De az tetszik hogy hasonló, de nem azonos kulcsszó legyen mutable és immutablenek.

num, int, float

Lehet, hogy a Number tényleg túl generic (bár elvileg JS-ben működik), de valószínűleg tényleg jobb lenne az elválasztás float és int félékre. De ennél több szerintem ne legyen, mert egy high level language-be felesleges double meg long meg ilyen szarokkal fárasztani a felhasználót.

tuple

Ha a tuple egy immutable lista akkor ne adjunk neki más nevet, hanem csak simán engedjük meg hogy a változódeklarációnál a lista lehessen immutable meg mutable és akkor nincs felesleges bonyolódás az új típus miatt.

dict

Ez már szerintem jobban különbözik a listától, mint a tuple, szóval a használatát támogatom. Amúgy ha nincs tuple, akkor lehet helyette dict-et is használni, nem csak listát. Ezen még érdemes gondolkodni. Szintaktikailag még nincs ötletem.
Elérést tekintve sima függvényre gondoltam: get(iter, n)

elnevezésről

Nézhetjük más nyelvek elnevezéseit, de ne népszerűség hanem általunk elbírált hasznosság (pl mennyire explicit) alapján értékeljük őket és az sem feltétlen baj, ha a javunkra javítunk rajtuk (pl filtertrue > filter)

egyéb

Úgy kéne megírni a nyelvet hogy később másnak is könnyű legyen frontend-et írnia hozzá. Moduláris dolog kéne mert most nem csak egy nyelvet csinálunk, hanem nyelvet, szintaxist, fejlesztői környezetet, stb
Kövi kommentbe írok egy listát hogy szerintem mi menjen mindenképpen a standardlib-be.

inkább átírtam az eredeti fájl és kivettem belőle a "nemfüggvényes" dolgokat. amikről még kell némi diskurzus:

• boolean-ek jelölése: #t vagy true
• függvénydeklarációnál a függvény neve(nekem az fnc és a function tetszik a legjobban)
• változódeklaráció neve (a var pl hülyeség, mert nem lesz feltétlen mutable szóval legyen a let, mert az talán a legismertebb és az immutable meg lehetne let forever lol)
• szerintem legyen most loop és ha nagyon nem illene bele a képbe, akkor kiszedjük
• a conditional statement-ek szintaxisára semmi ötletem nincs sajnos :(
• return, break, continue?
• globál és lokál változók kérdése
• importálással addig nem kell foglalkozni amíg csak stdlib-ünk van

szerintem kezdjünk el "próbaprogramokat" írni és nézzük meg hogy tudjuk e használni a nyelvet

; egysoros komment

{több
soros
komment}

; változó deklaráció, ami vesszővel van "denotálva"
('four: 4)

; egyszerű föggvény deklaráció, ami pedig hashtaggel van írva
(#plus_four x:
    (return sum(x 4)))

; hosszabb függvény deklaráció lokális változókkal
(#long_function x1 x2 x3:
    ('x1_plus_one: (sum x1 1))
    ('x2_plus_one: (sum x2 1))
    ('other_things: (prod x1_plus_one x2_plus_one x3))
    (return other_things))

; a log jobban tetszik mint a print, de nem ragaszkodom hozzá annyira
; amúgy ez meg egy függvény hívás
(log (long_function(1 2 3)))

; a listákat ugyanúgy kell deklarálni mint a változókat csak több elemet kapnak
('list_example: 1 2 3)

; így lehet függvényeket elérni index alapján
; bár ez annyira gyakori, hogy lehet érdemes rá egy szintaktikailag eltérő elemet bevezetni
(get list_example 1)

;a sztringeket meg doublequote-tal kell körülvenni
('string_example: "ez most egy sztring!")

Új ötlet

Ha a változókat függvényként kezeljük, akkor annak megvan az az előnye, hogy primitíveket is meg tudnánk hívni függvényként, ami megoldaná az index alapján elérés problémáját, mert szerintem az tök csúnya, hogy (get lista_neve index), de azért új szintaktikát sem szívesen vezetnék be. Szóval lehetne az hogy: (lista_neve index) és kész! Komolyabb dolgok még nem jutottak eszembe továbbá az sem világos, hogy milyen előnye van ennek a megoldásnak az int és float-okkal kapcsolatban.

bővített kiadás. kipróbáltam a per jelet vesszőnek

/ egysoros komment

{több
soros
komment}

/ változó deklaráció, ami vesszővel van "denotálva"
('four: 4)

/ egyszerű föggvény deklaráció, ami pedig hashtaggel van írva
(#plus_four x:
    (return sum(x 4)))

/ hosszabb függvény deklaráció lokális változókkal
(#long_function x1 x2 x3:
    ('x1_plus_one: (sum x1 1))
    ('x2_plus_one: (sum x2 1))
    ('other_things: (prod x1_plus_one x2_plus_one x3))
    (return other_things))

/ a log jobban tetszik mint a print, de nem ragaszkodom hozzá annyira
/ amúgy ez meg egy függvény hívás
(log (long_function(1 2 3)))

/ a listákat ugyanúgy kell deklarálni mint a változókat csak több elemet kapnak
('list_example: 1 2 3)

/ így lehet függvényeket elérni index alapján
/ bár ez annyira gyakori, hogy lehet érdemes rá egy szintaktikailag eltérő elemet bevezetni
(get list_example 1)

/ a sztringeket meg doublequote-tal kell körülvenni
('string_example: "ez most egy sztring!")

/ új ötlet: indexelérés mintha a lista maga egy függvény lenne
(list_example 1)

/ és akár sublist-et is el lehetne így érni
(list_example 0 2)

/ vagy ha kettőnél több paraméter van, akkor csak simán azokat az indexeket visszaadni
(list_example 0 1 2)

/ mínusz indexelés is király és mivel nem használjuk a mínusz jelet kivonáshoz,
/ így egyértelműbb a dolog jelentése
/ amúgy szerintem legyen kötelező space nélkül írni a mínusz jelet és a számot
(list_example -1)

/ amúgy ez stringeknél hasonlóan működne
(string_example 3 6) / ez azt adná vissza hogy "most"

/ hogyha a függvények first-class citizen-ek,
/ akkor igazából a for loop meg a map függvény elég hasonló lenne
(for (range 10) i 
    (log i))

/ és ez az if statement-eket is megkönnyítené
(if (any true false false)
    (log "ez bizony true")
    (log "ez itt az else ág"))

• 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