Reeds un parsēšana, kas atstāj pēdas

Lielākā daļa parseru pārvērš avotu pagaidu kokā un pēc tam izmet vērtīgos pierādījumus. Reed attiecas uz parsēšanu kā uz kaut ko tādu, ko CI, redaktori,...

Reeds un parsēšana, kas atstāj pēdas

Parsētājs parasti apēd pierādījumus

Katra programmatūras organizācija jau paļaujas uz parsētājiem. Kompilatori parsē. Linteri parsē. Redaktori parsē. Statiskā analīze parsē. Formatētāji parsē. Būvēšanas sistēmas parsē konfigurāciju, manifestus, bloķēšanas failus un avota kokus, līdz telpā smaržo pēc regulārajām izteiksmēm un nožēlas.

Tomēr lielākā daļa komandu parsēšanu uzskata par vienreizēju starpposmu. Process nolasa failu, izveido AST jeb parsēšanas koku atmiņā, to izmanto un pēc tam ļauj tam pazust. Ja vēlāk kāds jautā, vai binārais fails tika izveidots no apstiprināta avota, vai atkarība mainījās, vai laidienā bija iekļauta konkrēta funkcija, vai pārskats redzēja to pašu koku, ko CI, atbilde bieži kļūst sociāla. Uzticies būvējumam. Uzticies žurnāliem. Uzticies rīkam. Uzticies cilvēkam, kurš tagad ir atvaļinājumā.

Nopietnām piegādes ķēdēm ar to nepietiek. Avota kods nav tikai teksts. Tas ir pierādījums. Teksta formai ir nozīme. Attiecībām tajā ir nozīme. Tam, kā tas tika parsēts, ir nozīme. Ja šī struktūra pastāv tikai pazudušā procesa iekšienē, organizācija ir izmetusi to, kas vēlāk jāpierāda.

Reed pastāv tieši šai plaisai. Reed lapa to raksturo kā atvērtā pirmkoda parsētāju un izcelsmes slāni: GLL parsēšana, SPPF struktūra, Merkle koka identitāte, BLAKE3 sertifikātu saknes, RQL vaicājumi, CLI lietošana, redaktora integrācija, C ABI, WASM un Python saskarnes. Būtība nav tikai tajā, ka Reed parsē. Būtība ir tajā, ka parsēšana atstāj pārnēsājamu kvīti.

Reed parsēšanas koku uztver kā kaut ko tādu, kam vēlāk var piešķirt adresi, ko var nofiksēt un pārbaudīt, nevis kā pagaidu objektu, kas mirst līdz ar procesu.

Tā ir neliela izmaiņa formulējumā, bet liela izmaiņa pieejā. Parsētājs, kas atgriež noderīgu koku, ir izstrādātāja rīks. Parsētājs, kas atgriež noderīgu koku ar stabilu sakni, kļūst par būvēšanas infrastruktūru. Tagad CI var publicēt sakni. SBOM rīki to var ierakstīt. Laidiena process to var nofiksēt. Pārskatītājs to var salīdzināt. Revidents var uzdot jautājumu, neprasot, lai visi atjauno visumu teātra gaismās.

Būvējuma izcelsme sākas pirms binārā faila

Par būvējuma izcelsmi bieži runā cauruļvada beigās: parakstīts artefakts, SBOM, laidiena piezīme, izvietošanas apstiprinājums, varbūt informācijas panelis, kas saka "atbilst" ar tāda cilvēka pārliecību, kurš pārdod jumta izolāciju. Šīm daļām ir nozīme, bet tās ir novēlotas. Līdz tam avots jau ir izgājis cauri parsēšanai, kompilēšanai, transformācijai, apvienošanai un iepakošanai.

Ja avota struktūra nekad netika ierakstīta, laidiena kvītī vidū ir caurums. Jūs zināt, ka artefakts ir parakstīts. Jūs, iespējams, zināt commit jaucējvērtību. Bet vai varat parādīt parsētā avota formu, ko redzēja analīze? Vai varat pierādīt, ka ģenerēts binārais fails atbilst parsētam kokam ar to pašu sakni? Vai lejupstraumes patērētājs var pārbaudīt, ka iekļautā atkarība klusi nemainījās ar to pašu faila nosaukumu?

Reed noderīgais solījums ir ievietot pārbaudāmu objektu parsēšanas slānī. BLAKE3 sakne nav mārketinga dzeja. Tas ir kompakts identifikators parsētai struktūrai. Sertifikāts nav jauks paskaidrojums. Tas ir kaut kas, ko citi rīki var pārnēsāt. Tas padara parsēšanu par izcelsmes daļu, nevis miglainu soli starp git un bināro failu.

Tas vissvarīgāk ir tad, kad pienāk garlaicīgi jautājumi. Vai šis binārais fails tika izveidots no apstiprināta avota? Vai pārskatītais kods un izvietotais kods dalījās ar to pašu parsēto struktūru? Vai atkarība mainījās pēc apstiprināšanas? Kurš fails ieviesa mezglu, kas vēlāk kļuva par politikas jautājumu? Šie jautājumi nav eksotiski. Tie ir programmatūras atbildības pamatjautājumi. Mēs vienkārši turpinām izlikties, ka tie ir reti, jo rīki tos padara apgrūtinošus.

Viena labojuma vietā siena

Avota pārskatīšana zaudē jēgu, kad nelielas izmaiņas rada lielus, nelasāmus diff failus. Ikviens zina šo sajūtu. Vienas rindiņas izmaiņas liek ģenerētajam rezultātam pārkārtoties. Formatētājs maina apkārtējo tekstu. Parsers vai analīzes rīks pusi koka atzīmē kā jaunu. Pārskatīšana kļūst par sienu, un cilvēki dara to, ko cilvēki dara ar trokšņa sienām: viņi pārskrien acīm, nopūšas un apstiprina vairāk, nekā vajadzētu.

Reed satura adresētā pieeja piedāvā labāku mērķi. Ja nemainītie mezgli saglabā savu identitāti, neliela labojuma rezultātā struktūrā paliek neliels labojums. Apkārtējam kokam nav jākļūst aizdomīgam tikai tāpēc, ka viena zars ir pārvietojies. Tas nav tikai veiktspējas stāsts. Tas ir pārskatīšanas stāsts. Tas nozīmē, ka cilvēks var koncentrēties uz to, kas ir mainījies, nevis kaulēties ar rīku, kas katru otrdienu uzskata, ka viss ir jauns.

Laba izcelsme samazina troksni. Vērtīgais diff ir tā daļa, kas patiešām mainījusies, nevis katrs zars, kas gadījies tuvumā.

Šeit parsēšana kļūst operacionāla. Parasts parsers var būt pareizs un tomēr operacionāli neveikls. Ja tas izveido struktūru un izmet sakni, lejupstraumes rīkiem viss ir jāparsē, jāuzticas vai jāpārkārto no jauna. Ja tas reģistrē stabilu sertifikāta sakni, sistēma iegūst mazāku objektu salīdzināšanai. Mazākus objektus ir vieglāk automatizēt. Vieglāka automatizācija nozīmē mazāk rituālu. Mazāk rituālu nozīmē mazāk piektdienas pēcpusdienas apstiprinājumu, kas tiek izdarīti ar vienu aci uz vilcienu uz mājām.

Tas nav glamūrīgi. Tas ir ļoti noderīgi. Nozare bieži mēģina atrisināt uzticēšanos ar informācijas paneļiem, kad tai vispirms vajadzētu padarīt pamatā esošo objektu pietiekami stabilu salīdzināšanai.

Valodas dīvainības ir vieta, kur parseri mācās pazemību

Parsēšana diagrammās izskatās tīra. Ienāk tokeni. Iznāk koki. Tad ierodas īsta valoda un atnes atkāpes, neapstrādātas virknes, ligzdotus komentārus, heredoc, nowdoc, regex literāļus, kas izskatās pēc dalīšanas, interpolāciju, čaulas citēšanu, XML robežgadījumus un konfigurācijas formātus, kas acīmredzot izstrādāti domstarpību laikā.

Reed skenera materiāls ir interesants, jo tas šīs dīvainības uztver kā skaidras inženierijas problēmas. Atkāpes tiek izsekotas. Heredoc un nowdoc gadījumi pastāv. Ligzdoti bloku komentāri tiek modelēti. JavaScript un TypeScript regex pret dalīšanu ir atkarīgs no iepriekšējā tokena konteksta. Neapstrādātas virknes un interpolācija saņem savu apstrādi. Tieši šajā slānī izlikšanās kļūst dārga.

Mākslīgā intelekta sistēma, kas atkarīga no koda izpratnes, nevar uztvert parsēšanu kā noskaņojuma vingrinājumu. Drošības skeneris nevar palaist garām bloku tāpēc, ka valoda izmantoja dīvainu virknes formu. Dokumentācijas ieguvējs nevar klusi apēst heredoc un uzskatīt dienu par pabeigtu. Koda meklēšanas rīks nevar uzvesties atšķirīgi redaktorā, CI un Python skriptā tāpēc, ka katra integrācija izmantoja atšķirīgu parseri ar nedaudz atšķirīgām interpretācijām.

Nejaukās mazās sintakses detaļas nav blakus uzdevumi. Tās ir vieta, kur koda izpratne vai nu kļūst skaidra, vai sāk pieklājīgi melot.

Eksplicītie skeneri nav tikai par pareizību. Tie ir par to, lai noteikums būtu pietiekami redzams pārskatīšanai. Ja skeneris zina, kāpēc slīpsvītra ir regex, nevis dalīšana, šo faktu var pārbaudīt. Ja atkāpes rada INDENT un DEDENT žetonus, par šo uzvedību var spriest. Ja ligzdoti komentāri tiek atbalstīti līdz patvaļīgam dziļumam, pastāv noteikums, nevis paraustīti pleci. Paraustīti pleci nav parsēšanas stratēģija, lai gan daudzi koda bāzes to ir mēģinājušas.

Vienam dzinējam vajag daudzas durvis

Parsēšanas infrastruktūra kļūst dīvaina, kad katra virsma izveido savu versiju. CLI ir viena interpretācija. Redaktoram ir cita. CI skripts izsauc kaut ko citu. Python darbplūsma izsauc bināro failu. Pārlūkprogrammas rīks izmanto atsevišķu WASM būvi. Tad kāds jautā, kāpēc diagnostika atšķiras starp lokālo izstrādi un cauruļvadu. Atbilde parasti ir kopīgs dokuments, kuru neviens nezina.

Reed lapā ir aprakstīts saskaņotāks virsmas modelis: pamata parsēšanas dzinējs, CLI parsēšanas, vaicājumu un sertifikātu darbam, Language Server Protocol integrācija diagnostikai un navigācijai, stabilas C saistības ne-Rust viesiem, WASM un Python. Vērtība nav tajā, ka katra virsma pastāv pašas dēļ. Vērtība ir tajā, ka tās var runāt, izmantojot vienu un to pašu parsēšanas līgumu.

Virsmai jāmainās lietotājam, nevis nozīmei. CLI, redaktoram, saistībām un pārlūkprogrammas rīkiem jānorāda uz vienu un to pašu parsēšanas līgumu.

Šis līgums ir tas, kas Reed sader ar pārējo steku. Spindle var pārvaldīt zināšanas tikai tad, ja avota atomi ir pietiekami stabili, lai tiem uzticētos. AION un Trace var nest pierādījumus tikai tad, ja augšupstraumes artefaktiem ir identitātes. Ledger var ierakstīt notikumu, bet notikums ir spēcīgāks, ja tas norāda uz parsēšanas sakni, nevis uz neskaidru faila ceļu. Fabric var parādīt uz avotu balstītu atbildi, bet uz avotu balstīts ir mazāk iespaidīgi, ja avota koks maina formu atkarībā no tā, kurš rīks uz to skatījies.

Reed neaizstāj šos slāņus. Tas tiem dod labāku objektu. Tas ir pareizs darba dalījums. Rīki kļūst neuzticami, kad tie mēģina būt visa civilizācija. Reed parsē, veido jaucējvērtības, sertificē un atklāj virsmas. Ar to pietiek.

Veiktspējas skaitļi ir noderīgi, nevis galvenais stāsts

Reed lapā ir iekļautas konkrētas etalonu kategorijas: SIMD strukturālā skenēšana vairāku gigabaitu sekundē diapazonā, uz tabulām balstīta SLR parsēšana JSON, TOML, XML un Dockerfile formātiem, un lēnāka GLL parsēšana Rust ar pilnu CFG un neskaidrības atbalstu. Šie skaitļi ir noderīgi, jo tie nosaka cerības. Strukturālā skenēšana nav tas pats, kas parsētājs ar neskaidrības atbalstu. Ja kāds tos salīdzina, it kā tie būtu viens un tas pats, viņš ir vai nu apmulsis, vai arī kaut ko pārdod. Dažreiz abi.

Spēcīgāks stāsts nav viens varonīgs skaitlis. Tā ir darba forma. Izmantojiet ātrus strukturālus ceļus, kur formāts to atļauj. Izmantojiet smagāku parsēšanu, kur valoda to prasa. Saglabājiet sertifikāta sakni. Padariet rezultātu vaicājamu. Ļaujiet CI un audita rīkiem nest kompaktu faktu, nevis ugunskura stāstu.

Tā ir arī atšķirība starp etalonu teātri un inženieriju. Etalonam vajadzētu palīdzēt izvēlēties un noregulēt rīku. Tam nevajadzētu kļūt par rīka identitāti. Reed ir interesants, jo tā pierādījumu nostāja saglabājas pat tad, kad darba slodze mainās. JSON un Rust neprasa vienu un to pašu parsēšanas stratēģiju. Tie prasa vienu un to pašu nopietnību attiecībā uz kvītīm.

Kur Reed iederas

Reed pieder pirms koda inteliģences, pirms būvēšanas pierādījumiem, pirms uz avotu balstīta AI pār kodu un pirms jebkura audita, kas vēlas uzdot jautājumus par to, kas mainījies. Tas atrodas vietā, kur teksts kļūst par struktūru. Šī vieta ir svarīgāka, nekā izskatās, jo katrs vēlākais apgalvojums par kodu ir atkarīgs no tās.

Inženiertehniskajām komandām tūlītējā vērtība ir praktiska. Parsējiet vienreiz ar zināmu līgumu. Vaicājiet struktūrai, nevis grep juceklim. Publicējiet saknes CI vidē. Iekļaujiet sertifikātus izlaišanas pierādījumos. Saglabājiet redaktora, CLI un automatizācijas virsmu saskaņotību. Kad pārskatīšanā jautā, kas mainījies, atbildiet ar struktūru apzinošu kvīti, nevis ekrānuzņēmumu vai pārliecinošu rindkopu biļetē.

AI sistēmām Reed ir aizsargs pret ļoti mūsdienīgu muļķību veidu: koda izpratni, kas nevar atskaņot, kā tā saprata kodu. Ja AI asistents izskaidro funkciju, iesaka refaktorēšanu vai apliecina politikas īpašību, avota struktūrai aiz šīs atbildes jābūt pietiekami stabilai, lai to varētu pārbaudīt. Pretējā gadījumā asistents tikai lasa tējas lapas ar sintakses izcelšanu.

Mācība

Reed mācība ir vienkārša: parsēšana nav vienreizējs priekšspēle. Tā ir daļa no pierādījumu ķēdes. Ja parsētājs izmet noderīgo struktūru, lejupstraumes sistēmas manto uzticības problēmu un pēc tam pavada mēnešus, to dekorējot.

Laba parsēšanas kārta jāatstāj kvīti. Tai skaidri jāapstrādā valodas īpatnības. Tai jāsaglabā identitāte stabilu nelielu izmaiņu laikā. Tai jāatklāj tā pati nozīme caur CLI, redaktoru, ABI, WASM un skriptiem. Tai jāļauj būvēšanas, audita vai AI darbplūsmai norādīt uz kaut ko konkrētāku par "uzticieties mums, koks bija kārtībā, kad mēs skatījāmies".

Tā ir Reed noderīgā forma: ne parsētāja spožums, ne sintakses tūrisms, ne vēl viens rīks, kas rada JSON kaudzi un sauc to par ieskatu. Parsētāja kodols, kas pārvērš avotu pārbaudāmā struktūrā, ar saknēm un sertifikātiem, ko citas sistēmas var nest. Sauss darbs, jā. Svarīgs darbs parasti tāds ir. Spožā daļa nāk vēlāk, kad kaut kas saplīst un jūs varat faktiski pierādīt, kur.