Olen löytänyt useita avoimen lähdekoodin visuaalisia ohjelmointityökaluja, kuten Blockly ja ystävät, sekä muita Githubissa isännöityjä projekteja, mutta en löytänyt yhtään, joka toimisi suoraan abstrakti syntaksipuu.
Miksi?
I ”m kysyin, koska kun huomasin, että jokaisella siellä olevalla kääntäjällä on kokoamisprosessissa vaihe, jossa se jäsentää lähdekoodin AST: ksi, oli minulle selvää, että jotkut visuaaliset ohjelmointityökalut voisivat hyödyntää tätä antaakseen ohjelmoijalle tapoja muokata AST suoraan visuaalisesti, ja myös edestakaisen matkan lähteestä solmukaavioon ja sitten takaisin takaisin lähteeseen tarvittaessa.
Esimerkiksi voisi ajatella, että JavaScript AST Visualizer todelliseen JavaSript-visuaaliseen ohjelmointityökaluun ei ole liikaa eroa.
Joten , mitä minulta puuttuu?
Kommentit
- AST: t ovat hyvin yksityiskohtaisia, eivätkä ne ole kovin käteviä ohjelmoinnissa. Ne on suunniteltu kääntäjille, ei ohjelmoijille.
- fi.wikipedia.org/wiki/Structure_editor
- Mitä tehdä tarkoitat ” työskennellä suoraan abstraktin syntaksipuun kanssa ”? Epäilemättä kaikki lohkopohjaiset työkalut, kuten Blockly, muokkaavat AST: tä: ne edustavat reunoja pesimällä (tai pinoamalla, jos haluat nähdä sen näin), ja käyttäjä voi muokata puuta (esimerkiksi) vetämällä ja pudottamalla. / li>
- Se ’ on suuri kysymys, joka on monilla meistä, jotka pitävät kääntäjistä, on ollut. Mielestäni lyhyt vastaus on, että jos pystyt tekemään tämän ja tekemään siitä käyttäjäystävällisen, ihmiset käyttävät sitä. Ainoa ongelma on, että ’ sa iso ” jos ”.
- Oletko perehtynyt Lispiin ? ” [Se ’ s] ei niin paljon, että Lispillä olisi outo syntaksitapa kuin sillä, että Lispillä ei ole syntaksia. Kirjoitat jäsennyspuihin ohjelmia, jotka syntyvät kääntäjässä, kun muita kieliä jäsennetään. Mutta nämä jäsennyspuut ovat täysin käytettävissä ohjelmissasi. Voit kirjoittaa ohjelmia, jotka manipuloivat niitä. ”
Vastaa
Monet näistä työkaluista tekevät työtä suoraan abstraktin syntaksipuun kanssa (tai pikemminkin suoran yhden – yksi sen visualisointi). Tähän sisältyy Blockly, jonka olet nähnyt, sekä muut lohkopohjaiset kielet ja toimittajat, jotka pitävät siitä ( Scratch , Pencil Code / Pisara , Snap! , GP , Tiled Grace ja niin edelleen).
Nämä järjestelmät eivät ”t näyttävät perinteisen kärjen ja reunan kuvaajan esityksen muualla selitetyistä syistä (avaruus ja myös vuorovaikutuksen vaikeus), mutta ne edustavat suoraan puuta. Yksi solmu tai lohko on toisen lapsi, jos se on fyysisesti suoraan vanhemman sisällä.
Rakensin yhden näistä järjestelmistä ( Ruudullinen armo , paperi , paperi ). Voin vakuuttaa teille, että se toimii hyvin paljon suoraan AST: n kanssa: ruudulla näkyvä on tarkka kuvaus syntaksipuusta sisäkkäisinä DOM-elementteinä (eli puu!).
Tämä on joidenkin koodien AST. Juurihakemisto on menetelmäpuhelun solmu ”for … do”. Kyseisellä solmulla on joitain lapsia alkaen ”_ .. _”, jolla itsessään on kaksi lasta, ”1” solmu ja ”10” solmu. Näytöllä näkyy juuri se, mitä kääntäjän taustajärjestelmä sylkii keskellä prosessia – se on järjestelmän perusta.
Jos haluat, voit ajatella sitä tavallisena puun asetteluna. reunat osoittavat ulos näytöstä itseäsi kohti (ja niiden edessä oleva lohko sulkee ne), mutta pesiminen on yhtä pätevä tapa näyttää puu kuin kärkikaavio.
Se ”myös edestakainen matka lähteestä solmukaavioon ja sitten takaisin takaisin lähteeseen tarvittaessa. ”Itse asiassa näet, että se tapahtuu, kun napsautat alareunassa olevaa” Koodinäkymä ”. Jos muokkaat tekstiä, se” uudelleen jäsennetty ja tuloksena oleva puu hahmonnettu muokkausta varten uudelleen, ja jos muokkaat lohkoja, sama tapahtuu myös lähteen kanssa.
Pencil Code tekee tässä vaiheessa olennaisesti saman asian, parempi käyttöliittymä . Sen käyttämät lohkot ovat graafinen näkymä CoffeeScript AST: stä.Niin tekevät myös muut lohko- tai laattapohjaiset järjestelmät, vaikka jotkut niistä eivät tee pesimisen näkökulmaa aivan yhtä selkeäksi visuaalisessa esityksessä, ja monilla ei ole todellista tekstikieltä takana, joten ” syntaksipuu ”voi olla hieman harhainen, mutta periaate on olemassa.
Sinulta puuttuu siis se, että nämä järjestelmät todella toimivat suoraan abstrakti syntaksipuu. Se, mitä näet ja käsittelet, on puun avaruustehokas renderöinti, monissa tapauksissa kirjaimellisesti AST, jonka kääntäjä tai jäsennin tuottaa.
Vastaa
Ainakin kaksi syytä:
-
Koska lähdekoodi on paljon ytimekkäämpi esitys. AST: n asettaminen kaaviona vie paljon enemmän visuaalista kiinteistöä.
Ohjelmoijat palkitsevat mahdollisimman paljon kontekstia – ts. jos näytöllä on yhtä paljon koodia kerralla samanaikaisesti. Konteksti auttaa heitä paremmin hallitsemaan monimutkaisuus. (Se on yksi syy, miksi monet edistyvät ammers käyttävät näitä hulluja pieniä kirjasimia ja valtavia 30 tuuman näyttöjä.)
Jos yritämme näyttää AST: n kaaviona tai puuna, koodin määrä, joka mahtuisi yhdelle näytölle, olisi paljon pienempi kuin kun se esitetään lähdekoodina. Se on valtava menetys kehittäjien tuottavuudelle.
-
AST on tarkoitettu kääntäjän ohjelmointiin, ei ohjelmoijien helppoon ymmärtämiseen. Jos otit olemassa olevan AST-esityksen ja näytät sen visuaalisesti, kehittäjien olisi todennäköisesti vaikeampaa ymmärtää, koska AST: itä ei ole suunniteltu niin, että kehittäjät voivat oppia sen helposti.
Lähdekoodi sen sijaan on yleensä on suunniteltu kehittäjien luettavaksi / ymmärrettäväksi; se on yleensä kriittinen suunnittelukriteeri lähdekoodille, mutta ei AST: lle. AST: n täytyy ymmärtää vain kääntäjien kirjoittajien, ei päivittäisten kehittäjien.
Ja joka tapauksessa, AST-kieli olisi toinen kieli, jonka kehittäjien on opittava lähdekielen lisäksi. Ei voittoa.
Katso myös https://softwareengineering.stackexchange.com/q/119463/34181 muutamia mahdollisia syitä.
Kommentit
- ” Lähdekoodi on sitä vastoin suunniteltu kehittäjien luettavaksi / ymmärrettäväksi ” – vasta-esimerkki: useimmat esolangit, Perl, Lisp
- ” Becaus e-lähdekoodi on paljon suppeampi esitys. ”; ” AST-kieli olisi toinen kieli, jonka kehittäjien on opittava lähdekielen ” lisäksi – nämä ovat argumentteja
kaikki visuaaliset PL: t, mutta ei auta selittämään eroa, josta OP on huolissaan. - ” (That ’ on yksi syy, miksi monet ohjelmoijat käyttävät näitä hulluja pieniä fontteja ja valtavia 30 ” näyttöä.) ” – jos tarvitset iso perse -näytön, jotta voit tarkastella tarpeeksi kontekstia, ehkä ’ koodaat uudelleen spagettia? 😉
- @Raphael Ehkä, mutta ’ on vähemmän vaivaa heittää rahaa siihen kuin refraktoida!
- @JanDvorak, .. .LISP on vasta-esimerkki, koska AST on kieli – mikä antaa sille sen ilmaisuvoiman; LISP-koodin kirjoittaminen, joka kääntää toisen LISP-koodisi uudelleen, on yhtä helppoa kuin koodin kirjoittaminen, joka muuttaa tavanomaisia LISP-tietorakenteita … jotka ovat juuri sellaisia, joihin LISP-koodi kirjoitetaan . Siellä ’ sa syystä se kesti ’ s yli puoli vuosisataa – perhe ’ Suunnittelu on harvoin ilmeikäs. Go: n asynkronisten laajennusten täytyi olla syvällä kielessä ja ajonaikana; Clojurelle se ’ on vain kirjasto. Katso myös: Keskiarvojen voittaminen .
Vastaa
Kääntäjien tyypillinen AST on melko monimutkainen ja monipuolinen. Suunnatusta kuvaajan esityksestä tulisi nopeasti melko vaikea seurata. Mutta CST: llä on kaksi suurta aluetta, joissa käytetään AST: itä.
- Lisp-kielet kirjoitetaan itse asiassa AST-kielinä. Ohjelman lähdekoodi kirjoitetaan luetteloina ja kääntäjä ja / tai tulkki käyttää sitä suoraan (riippuen käytettävästä muunnoksesta).
- Mallinnuskielet, esim. UML ja monet visuaaliset verkkotunnuskohtaiset kielet käyttävät graafisia merkintöjä, jotka ovat tehokkaita abstrakteja syntaksigrafiikkoja (ASG) korkeammalla abstraktiotasolla kuin tyypillinen yleiskielinen AST.