Elixir, můj nový oblíbený programovací jazyk (diskuse)

[Radek Miček]

BTW ten faktoriál mi přijde přehlednější v Erlangu.

je to jazyk, jehož vnitřní reprezentace (AST) je stejná jako jeho syntax (je mu izomorfní)

Zcela jistě platí, že když je to stejné, tak je to i izomorfní. Naopak už to platit nemusí.

Krom toho bych pochyboval o správnosti slova izomorfní v té definici.

[Ivorne]

Izomorfismus je jasně definovaný pojem a nevidím důvod, proč by tuto vlastnost nemohl programovací jazyk mít.

[Radek Miček]

Protože by tím pojem homoikonicity ztratil smysl. Chcete-li v programovacím jazyce reprezentovat nějaké objekty, tak je celkem přirozené pokusit se o izomorfní reprezentaci. Tudíž nedefinujete nic zajímavého.

Např. aritmetický výraz

a+b*c

může být reprezentován jako

Expr(Plus, Var "a", Expr(Mult, Var "b", Var "c"))

a bude to izomorfní reprezentace. Budete však takový jazyk nazývat homoikonický?

[Ivorne]

No já vlastně slyším pojem homoikonicita prvně, takže spíš píšu, co si tak myslím. Každopádně mezi uvedenými výrazy nevidím velký rozdíl. To první je infixový zápis a to druhé je prefixový zápis. Nevidím problém, proč by to nemohlo být homoikonické - netvrdím, že to je homoikonické, jen mě teď nenapadá, proč by nemohlo.

[Radek Miček]

Každopádně mezi uvedenými výrazy nevidím velký rozdíl.

Tohle ale platí pro většinu programovacích jazyků. Tím pádem to není zajímavé.

Na druhou stranu, pokud budeme chtít skutečně izomorfismus mezi konkrétní syntaxí (co píše programátor) a AST, tak ten nebude skoro nikde – např. různé zápisy téhož se naparsují na 1 AST – konkrétním příkladem může být různý počet mezer na konci programu.

[Ivorne]

Každopádně mezi uvedenými výrazy nevidím velký rozdíl.

Tohle ale platí pro většinu programovacích jazyků. Tím pádem to není zajímavé.

Tak řada jazyků nemá výsledný kód izomorfní se zdrojovým kódem - z kompilovaných jazyků to nemá žádný a například jazyky nad JVM to taky nemají (bytekód je kód zásobníkového počítače). A dokážu si představit, že když si člověk nedá pozor, tak se mohou objevit rozdíly mezi zdrojákem a AST i u čistě interpretovaných jazyků.

Co jiného, než izomorfismus zdrojového a výstupního kódu by mělo být zajímavé?

Na druhou stranu, pokud budeme chtít skutečně izomorfismus mezi konkrétní syntaxí (co píše programátor) a AST, tak ten nebude skoro nikde – např. různé zápisy téhož se naparsují na 1 AST – konkrétním příkladem může být různý počet mezer na konci programu.

Nevím, proč by to měl být problém. I více reprezentací může být navzájem izomorfní. Jak to vidím já, tak programy s různým počtem mezer na konci jsou spolu izomorfní.

[Radek Miček]

Nevím, proč by to měl být problém. I více reprezentací může být navzájem izomorfní. Jak to vidím já, tak programy s různým počtem mezer na konci jsou spolu izomorfní.

Pokud se dva programy s různým počtem mezer na konci naparsují na stejný AST, tak už parsování nemůže být izomorfismus, neboť nemůže existovat levý inverz.

Nevím, proč by to měl být problém. I více reprezentací může být navzájem izomorfní.

Pokud máte na mysli ekvivalentní místo izomorfní, tak ano.

Tak řada jazyků nemá výsledný kód izomorfní se zdrojovým kódem

Myslel jsem, že tu jde o izomorfismus mezi AST a zdrojovým kódem.

[random]

Pokud se dva programy s různým počtem mezer na konci naparsují na stejný AST, tak už parsování nemůže být izomorfismus, neboť nemůže existovat levý inverz.

Homoikonicita se zabývá programem na syntaktické, nikoliv lexikální úrovni.

[Radek Miček]

Co přesně myslíte syntaktickou úrovní?

Mj. bavíme se o definici

je to jazyk, jehož vnitřní reprezentace (AST) je stejná jako jeho syntax (je mu izomorfní)

a já jsem si pod syntaxí představil konkrétní syntax, tj. zdrojový kód. Ještě bych si mohl představit abstraktní syntax, tj. AST, ale to by ta definice pak byla tautologie.

[AsciiWolf]

BTW ten faktoriál mi přijde přehlednější v Erlangu.

+1

[Jan33]

Díky za post, i když to nevyužuju, je dobré o tom vědět. Budu sledovat.

[:::]

z wikipedie:

If a language is homoiconic, it means that the language text has the same structure as its abstract syntax tree

Existuji snad jazyky kde tohle neplati? Jaky smysl by melo vytvaret AST ktery nezachycuje strukturu kodu?

[Bystroushaak]

Není také jednou z podmínek, že z toho zdroje máš k tomu AST přístup?

[pavlix]

To není odpověď na položenéé otázky.

[random]

Ale je to důležité. Homoikonicita (jak ji chápu já) znamená, že AST je

1. jednoduchý,
2. přístupný a
3. editovatelný.

Samozřejmě, že skoro každý AST, který přímo vznikne naparsováním zdrojáku (čili bez optimalizací a tak) tomu zdrojáku odpovídá. Ale jak se třeba naparsuje posloupnost příkazů v Céčku?

a();
b = c + d;
e(b);

Vznikne z toho strom, ve kterém kořen odpovídá celému bloku kódu a v jeho synech jsou jednotlivé příkazy, nebo z toho vznikne spoják těch příkazů? Podle toho, co potřebuju, je výhodnější buď to první, nebo to druhé. Zdrojáku pochopitelně odpovídají obě možnosti, záleží na tom, jak se na něj dívám.

[pavlix]

Homoikonicita (jak ji chápu já) znamená, že AST je jednoduchý, přístupný a editovatelný.

To by musel být zcela nevhodně zvolený pojem. Z jeho názvu se zdá, že znamená, že máš více věcí a jsou v něčem stejné, v tomto případě jsem to pochopil tak, že se mají ve struktuře shodovat kód a AST, ale to jsem vždycky považoval za samozřejmost. Jediné, co mě napadá je, že chtějí nějak explicitně vyjádřit absenci preprocessingu, optimalizací a podobných věcí. A protože jim přišlo hloupé se vytahovat absencí funkcionality (byť dobře odůvodněnou), tak tomu chtěli dát nějaký pozitivní název.

Vznikne z toho strom, ve kterém kořen odpovídá celému bloku kódu a v jeho synech jsou jednotlivé příkazy, nebo z toho vznikne spoják těch příkazů?

Když z toho uděláš strom, vznikne z toho kupodivu strom. Zda je ten strom reprezentován v paměti pomocí spojových seznamů, je implementační detail. Žádné dvě možnosti v tom nevidím.

[random]

Když z toho uděláš strom, vznikne z toho kupodivu strom. Zda je ten strom reprezentován v paměti pomocí spojových seznamů, je implementační detail. Žádné dvě možnosti v tom nevidím.

Ano, AST je strom. Bavím se o tom, jak ten strom vypadá. Je plochý (otec s mnoha syny) nebo vysoký (hlava a ocas)?

Bison:

commands: command
        | commands SEMICOLON command
        ;

Z tohohle přímočarým způsobem vyjde ten spoják. Na editaci ale není nic moc, protože ho při každé změně musím procházet.

Implementační detail to není, protože se jedná o rozhraní.

[pavlix]

Obávám se, že se zcela míjíme.

[pavlix]

Samozřejmě, že skoro každý AST, který přímo vznikne naparsováním zdrojáku (čili bez optimalizací a tak) tomu zdrojáku odpovídá.

Ty optimalizace dokonce zmiňuješ, pak je tu ještě ten preprocessing, protože makra jsou třeba v céčku řešena zcela nezávisle na AST. Na druhou stranu bych očekával, že makra pracující s AST projdou preprocesingem a z toho AST během své expanze úplně zmizí, takže by ten výsledný AST taky nemusel vypadat jako původní kód, jen by byl z něj dobře předvídatelný.

[pavlix]

Wikipedia:

If a language is homoiconic, it means that the language text has the same structure as its abstract syntax tree (i.e. the AST and the syntax are isomorphic). This allows all code in the language to be accessed and transformed as data, using the same representation.

Mně se zdá spojení mezi těmi dvěma větami úplně vycucané z prstu. To zda můžu vystavět či upravovat kód v AST přece záleží jenom na tom, zda k tomu AST dostanu přístup. Pokud bych měl céčko kompilované do speciálního prostředí, kde budu mít za běhu přístup k AST funkcí a rutiny na manipulaci s ním, pak budu přistupovat ke kódu jako k datům přesně tak jak to píšou. To je ale především vlastnost běhového prostředí, takže jediné, co pro to může udělat jazyk je mít ve specifikaci, že vyžaduje takové běhové prostředí a případně nabízet nějaký ten syntaktický cukr.

[Ivan]

Asi se tim mysli i opacna "konverze". Tzn: z AST muzu zase dostat nazpatek cely zdrojak (az na komentare a mezery). Tohodle napriklad vyuzivaji ruzne udelatory v eclipse pro refactoring.

Souhlasim s tim, ze tohle hlavne runtime toho jazyka a API pro pristup k tomu AST. A asi se s tim da hodne prasit, v porovnani s obycejnou reflexi (jako se to dela v Jave). Tam mate pristup pouze k definicim trid a metod.

[Milan]

No ja radsi primo Erlang.

[kralyk z abclinuxu]

Výraz

scale(translate(multiply(matrix1, matrix2), vector), 0.5)

se dá v Elixiru zapsat takto:

matrix1
|> multiply(matrix2)
|> translate(vector)
|> scale(0.5)

Co je pro vás čitelnější?

Z mého pohledu je pro takovýhle případ nejčitelnější chaining, tzn:

matrix1.multiply(matrix2).translate(vector).scale(0.5)

Ale o Erlangu vim prd, takže nevim, jestli tam je tohle možný...

[JS1]

Rekl bych, ze v tom Elixiru to muze tak napsat taky, akorat misto tecky pises |>.

[pavlix]

Až na to, že ten chaining funguje jen na několik vyjmenovaných operací, které jsou součástí API nějakého objektu.

[kralyk z abclinuxu]

To už záleží na konkrétním jazyce, jinak nechtěl jsem tím říct, že to je ekvivalentní (není)...

[Kaiten]

Haskell -> operátor funkční kompozice, houby objekty

[pavlix]

Context error.

[.]

Mozna to bude znit divne, denne profesionalne programuju v Erlangu i LFE, ale psat cokoliv v Elixiru mi vzdycky z nejakeho duvodu bylo neprijemne. Jako pipe operator je pekny, ale to je asi tak vsechno, co mi na Elixiru prijde zajimave. Mozna to je tim, ze jsem k Erlangu prisel smerem od LISPu a SmallTalku a ne pres Ruby...

Just my $.2

[pavlix]

To je dvacet centů?

[.]

Ano, ale ten zapis s uvedenymi jazyky nijak nesouvisi :)

[hadson]

Ja som na erlang presiel z F# (z krltoreho elixir prebral ten |>) a syntax erlangu mi tiez pride omnoho prehladnejsia. Elixir mi svojou zbytocnou ukecanostou pripomina Basic.