නිත්‍ය ප්‍රකාශන සින්ටැක්ස් නිර්මාණයේ කියවීමේ දුර්වලතාවයට නිශ්චිත හේතුවක් තිබේද?

162

මෙම තනතුර වැඩි දියුණු කිරීමට අවශ්‍යද? උපුටා දැක්වීම් සහ ඔබේ පිළිතුර නිවැරදි වන්නේ මන්ද යන්න පිළිබඳ පැහැදිලි කිරීමක් ඇතුළුව මෙම ප්‍රශ්නයට සවිස්තරාත්මක පිළිතුරු සපයන්න. ප්‍රමාණවත් විස්තර නොමැතිව පිළිතුරු සංස්කරණය හෝ මකා දැමිය හැකිය.

වැඩ කරන කෙටි-සින්ටැක්ස් සහිත එක්-ලයිනර් වලට වඩා කේත කියවීමේ හැකියාව වඩා වැදගත් බව ක්‍රමලේඛකයින් සියලු දෙනාම එකඟ වන නමුත් ජ්‍යෙෂ් senior සංවර්ධකයෙකු ඕනෑම නිරවද්‍යතාවයකින් අර්ථ නිරූපණය කිරීම අවශ්‍ය වේ - නමුත් එය සාමාන්‍ය ප්‍රකාශන නිර්මාණය කළ ආකාරයටම පෙනේ. මේ සඳහා හේතුවක් තිබේද?

selfDocumentingMethodName()එය වඩා හොඳ බව අපි කවුරුත් එකඟ වෙමු e(). සාමාන්‍ය ප්‍රකාශන සඳහාද එය අදාළ නොවන්නේ ඇයි?

ව්‍යුහාත්මක සංවිධානයක් නොමැති එක්-පේළියේ තර්කනයක වාක්‍ය ඛණ්ඩයක් නිර්මාණය කරනවාට වඩා මට පෙනේ:

var parse_url = /^(?:([A-Za-z]+):)?(\/{0,3})(0-9.\-A-Za-z]+)(?::(\d+))?(?:\/([^?#]*))?(?:\?([^#]*))?(?:#(.*))?$/;

මෙය URL එකක් තදින් විග්‍රහ කිරීම පවා නොවේ!

ඒ වෙනුවට, අපට මූලික උදාහරණයක් සඳහා, නල මාර්ග ව්‍යුහයක් සංවිධානාත්මකව හා කියවිය හැකි ලෙස සකස් කළ හැකිය:

string.regex
   .isRange('A-Z' || 'a-z')
   .followedBy('/r');

නිත්‍ය ප්‍රකාශනයක අතිශය දැඩි වාක්‍ය ඛණ්ඩය කෙටිම ක්‍රියාකාරිත්වය සහ තර්කන වාක්‍ය ඛණ්ඩය හැර වෙනත් වාසියක් ලබා දෙන්නේ කෙසේද? අවසාන වශයෙන්, නිත්‍ය ප්‍රකාශන සින්ටැක්ස් නිර්මාණයේ දුර්වල කියවීමේ හැකියාව සඳහා නිශ්චිත තාක්ෂණික හේතුවක් තිබේද?

readability regular-expressions

— විශාරද
source

අදහස් දීර් discussion සාකච්ඡාවක් සඳහා නොවේ; මෙම සංවාදය චැට් කිරීමට ගෙන ගොස් ඇත .

— maple_shaft

1

RegexToolbox නම් පුස්තකාලයක් සමඟ මෙම කියවීමේ හැකියාව හරියටම විසඳීමට මම උත්සාහ කර ඇත්තෙමි. මෙතෙක් එය C #, Java සහ JavaScript වෙත ගෙන ගොස් ඇත - github.com/markwhitaker/RegexToolbox.CSharp බලන්න .

— මාර්ක් විටේකර්

මෙම ගැටළුව විසඳීම සඳහා බොහෝ උත්සාහයන් ගෙන ඇති නමුත් සංස්කෘතිය වෙනස් කිරීම දුෂ්කර ය. වාචික ප්‍රකාශන පිළිබඳ මගේ පිළිතුර මෙතැනින් බලන්න . ලබා ගත හැකි අඩුම පොදු මෙවලම සඳහා මිනිසුන් ළඟා වේ.

— පරිවර් සරෆ්

180

නිත්‍ය ප්‍රකාශන ඒවා දැඩි ලෙස නිර්මාණය කිරීමට එක් විශාල හේතුවක් තිබේ: ඒවා සැලසුම් කර ඇත්තේ කේත සංස්කාරකවරයෙකුගේ විධාන ලෙස මිස කේත කිරීමට භාෂාවක් ලෙස නොවේ. වඩාත් නිවැරදිව, edනිත්‍ය ප්‍රකාශන භාවිතා කළ පළමු වැඩසටහන් වලින් එකකි , එතැන් සිට නිතිපතා ප්‍රකාශන ලෝක ආධිපත්‍යය සඳහා ඔවුන්ගේ ජයග්‍රහණය ආරම්භ කළේය. නිදසුනක් ලෙස, edවිධානය g/<regular expression>/pඉතා ඉක්මණින් වෙනම වැඩසටහනක් සඳහා ආභාෂය ලබා දුන් grepඅතර එය අදටත් භාවිතයේ පවතී. නිසා තම බලය, ඔවුන් ඉන් පසු වැනි විවිධ මෙවලම් දී සම්මත භාවිතා කරන ලදී sedසහvim

නමුත් සුළු කාරණා සඳහා ප්‍රමාණවත්. ඉතින් මෙම සම්භවය ව්‍යාකරණ ව්‍යාකරණයට කැමති වන්නේ ඇයි? ඔබ එය නැවත වරක් කියවීමට සංස්කාරක විධානයක් ටයිප් නොකරන නිසා. එය එකට දැමිය යුතු ආකාරය ඔබට මතක තබා ගත හැකි අතර ඔබට අවශ්‍ය දේ සමඟ එය කළ හැකිය. කෙසේ වෙතත්, ඔබ ටයිප් කිරීමට ඇති සෑම අක්ෂරයක්ම ඔබේ ගොනුව සංස්කරණය කිරීමේ ප්‍රගතිය මන්දගාමී කරයි. නිත්‍ය ප්‍රකාශන වාක්‍ය ඛණ්ඩය නිර්මාණය කර ඇත්තේ සාපේක්ෂව සංකීර්ණ සෙවුම් ඉවතලන ආකාරයෙන් ලිවීමට වන අතර, එය හරියටම වැඩසටහනකට යම් ආදානයක් විග්‍රහ කිරීම සඳහා කේතයක් ලෙස භාවිතා කරන පුද්ගලයින්ට හිසරදය ලබා දෙයි.

— cmaster - මොනිකා නැවත ස්ථාපනය කරන්න
source

5

regex විග්‍රහ කිරීමට අදහස් නොකෙරේ. එසේ නොමැතිනම් , stackoverflow.com/questions/1732348/… . සහ හිසරදය.

— njzk2

19

answer njzk2 එම පිළිතුර ඇත්ත වශයෙන්ම වැරදිය. HTML ලේඛනයක් සාමාන්‍ය භාෂාවක් නොව, HTML විවෘත ටැගයක් වන අතර එය ප්‍රශ්නය අසන්නේ ඇත්ත වශයෙන්ම ය.

— සසම්භාවී 832

11

මෙය මුල් රීජෙක්ස් තරම් ගුප්ත වන්නේ මන්දැයි පැහැදිලි කරන හොඳ පිළිතුරකි, නමුත් වැඩි කියවීමේ හැකියාව සහිත විකල්ප ප්‍රමිතියක් දැනට නොමැති වීමට එය පැහැදිලි නොකරයි.

— ඩොක් බ්‍රවුන්

13

එබැවින් grepවැරදි ලෙස උච්චාරණය කරන ලද “උදුරා ගැනීමක්” යැයි සිතන අයට එය සැබවින්ම පැමිණෙන්නේ g/ re(නිත්‍ය ප්‍රකාශනය සඳහා) / p?

— හේගන් වොන් එයිට්සන්

6

An ඩැනී ප්ලග්හෝෆ්ට් නැත, එය එසේ නොවේ. විවෘත ටැගයක් යනු <aaa bbb="ccc" ddd='eee'>එය තුළ කූඩුවල කිසිදු කූඩුවක් නොමැත. ඔබට කූඩු ටැග් කළ නොහැක, ඔබ කැදැල්ල යනු මූලද්‍රව්‍යයන්ය (විවෘත ටැගය, ළමා අංග ඇතුළුව අන්තර්ගතය, සමීප ටැගය), එය විග්‍රහ කිරීම ගැන ප්‍රශ්නය අසන්නේ නැත . HTML ටැග් යනු සාමාන්‍ය භාෂාවකි - සමතුලිතතාවය / කැදැල්ල සිදුවන්නේ ටැග් වලට වඩා ඉහළ මට්ටමක ය.

— සසම්භාවී 832

62

ඔබ උපුටා දක්වන නිත්‍ය ප්‍රකාශනය භයානක අවුලක් වන අතර එය කියවිය හැකි යැයි කිසිවෙකු එකඟ නොවනු ඇතැයි මම නොසිතමි. ඒ අතරම, එම කැතකම බොහෝමයක් විසඳීමට ඇති ගැටලුවට ආවේණික ය: කැදැලි ස්ථර කිහිපයක් ඇති අතර URL ව්‍යාකරණ සාපේක්ෂව සංකීර්ණ ය (නිසැකවම ඕනෑම භාෂාවකින් සංක්ෂිප්තව සන්නිවේදනය කිරීමට නොහැකි තරම් සංකීර්ණ ය). කෙසේ වෙතත්, මෙම රීජෙක්ස් විස්තර කරන දේ විස්තර කිරීමට වඩා හොඳ ක්‍රම ඇති බව නිසැක ය. ඉතින් ඒවා භාවිතා නොකරන්නේ ඇයි?

විශාල හේතුවක් වන්නේ අවස්ථිති බව හා සර්වසම්පූර්ණකමයි. මුලින් ඔවුන් එතරම් ජනප්‍රිය වූයේ කෙසේද යන්න එය පැහැදිලි නොකරයි, නමුත් දැන් ඔවුන් සිටින විට, නිත්‍ය ප්‍රකාශන දන්නා ඕනෑම කෙනෙකුට මෙම කුසලතා (උපභාෂා අතර ඉතා සුළු වෙනස්කම් සහිතව) විවිධ භාෂා සියයකින් සහ අතිරේක මෘදුකාංග මෙවලම් දහසකින් භාවිතා කළ හැකිය. උදා: පෙළ සංස්කාරක සහ විධාන රේඛා මෙවලම්). මාර්ගය වන විට, වැඩසටහන් ලිවීමට සමාන විසඳුමක් භාවිතා කිරීමට නොහැකි වූ අතර ඒවා ක්‍රමලේඛකයින් නොවන අය විසින් අධික ලෙස භාවිතා කරයි.

එසේ තිබියදීත්, නිත්‍ය ප්‍රකාශන බොහෝ විට ඕනෑවට වඩා භාවිතා කරයි, එනම් වෙනත් මෙවලමක් වඩා හොඳ වූ විට පවා අදාළ වේ. මම හිතන්නේ නැහැ රීජෙක්ස් සින්ටැක්ස් දරුණුයි කියලා . නමුත් එය කෙටි හා සරල රටාවන්ගෙන් පැහැදිලිවම වඩා හොඳය: සී වැනි භාෂාවලින් හඳුනාගැනීම් පිළිබඳ පුරාවිද්‍යාත්මක උදාහරණය, [a-zA-Z_][a-zA-Z0-9_]*අවම වශයෙන් රීජෙක්ස් දැනුමෙන් කියවිය හැකි අතර , එම තීරුව සපුරා ගත් පසු එය පැහැදිලිව හා මනාව සංක්ෂිප්ත වේ. අඩු අක්ෂර අවශ්‍ය වීම සහජයෙන්ම නරක නැත, තරමක් ප්‍රතිවිරුද්ධයයි. සංක්ෂිප්තව සිටීම ඔබට තේරුම්ගත හැකි මට්ටමක පවතී.

මෙම වාක්‍ය ඛණ්ඩය මෙවැනි සරල රටාවන්ගෙන් විශිෂ්ට වීමට හේතු දෙකක්වත් තිබේ: එයට බොහෝ අක්ෂර සඳහා පැන යාම අවශ්‍ය නොවේ, එබැවින් එය සාපේක්ෂව ස්වභාවිකව කියවන අතර, විවිධාකාර සරල විග්‍රහ කිරීමේ සංයෝජක ප්‍රකාශ කිරීමට එය ලබා ගත හැකි සියලුම විරාම ලකුණු භාවිතා කරයි. සමහර විට වඩාත් වැදගත් වන්නේ, එය අවශ්ය නොවේ සියලු දී ඕනෑම දෙයක් අනුකමණය සඳහා. ඔබ පළමුව ලියන්නේ, පසුව එන දෙයයි. ඔබගේ මෙම වෙනස followedByකිරීමේ දී පහත සඳහන් වේ, විශේෂයෙන්ම නොවන සත්ය නමුත් වඩාත් සංකීර්ණ ප්රකාශනයක්.

ඉතින් වඩාත් සංකීර්ණ අවස්ථාවන්හිදී ඒවා අඩුවන්නේ ඇයි? මට ප්‍රධාන ගැටළු තුනක් දැකිය හැකිය:

වියුක්ත කිරීමේ හැකියාවන් නොමැත. න්‍යායාත්මක පරිගණක විද්‍යාවේ එකම ක්ෂේත්‍රයෙන් රීජෙක්ස් ලෙස ආරම්භ වන විධිමත් ව්‍යාකරණ, නිෂ්පාදන සමූහයක් ඇති බැවින් රටාවේ අතරමැදි කොටස් වලට නම් ලබා දිය හැකිය:
```
# This is not equivalent to the regex in the question
# It's just a mock-up of what a grammar could look like
url      ::= protocol? '/'? '/'? '/'? (domain_part '.')+ tld
protocol ::= letter+ ':'
...
```
අපට ඉහත දැකිය හැකි පරිදි, ඇස්වලට පහසු වන හැඩතල ගැන්වීමට අවසර දීමට විශේෂ වැදගත්කමක් නැති සුදු අවකාශය ප්‍රයෝජනවත් වේ. අදහස් දැක්වීමේදී එකම දේ. නිත්‍ය ප්‍රකාශනවලට එය කළ නොහැක්කේ අවකාශයක් යනු එයම වචනානුසාරයෙන් වන ' 'බැවිනි. සටහන: සමහර ක්‍රියාත්මක කිරීම් මඟින් හිස් අවකාශය නොසලකා හරින සහ අදහස් දැක්විය හැකි "වාචික" මාදිලියකට ඉඩ ලබා දේ.
පොදු රටා සහ සංයෝජක විස්තර කිරීමට මෙටා-භාෂාවක් නොමැත. නිදසුනක් ලෙස, කෙනෙකුට digitවරක් රීතියක් ලිවිය හැකි අතර එය සන්දර්භය රහිත ව්‍යාකරණයක භාවිතා කළ හැකිය, නමුත් කෙනෙකුට “ශ්‍රිතයක්” නිර්වචනය කළ නොහැක, එබැවින් නිෂ්පාදනයක් ලබා දී pඑය සමඟ අමතර යමක් කරන නව නිෂ්පාදනයක් නිර්මාණය කරයි, උදාහරණයක් ලෙස සාදන්න කොමා මඟින් වෙන් කරන ලද සිදුවීම් ලැයිස්තුවක් සඳහා නිෂ්පාදනයක් p.

ඔබ යෝජනා කරන ප්‍රවේශය නිසැකවම මෙම ගැටලු විසඳයි. එය ඒවා හොඳින් විසඳන්නේ නැත, මන්ද එය අවශ්‍ය ප්‍රමාණයට වඩා සංක්ෂිප්තව වෙළඳාම් කරන බැවිනි. පළමු ගැටළු දෙක විසඳිය හැක්කේ සාපේක්ෂව සරල හා දැඩි වසම්-විශේෂිත භාෂාවක් තුළ ය. තෙවනුව, හොඳයි ... ක්‍රමලේඛ විසඳුමකට ඇත්ත වශයෙන්ම පොදු අරමුණු ක්‍රමලේඛන භාෂාවක් අවශ්‍ය වේ, නමුත් මගේ අත්දැකීම් අනුව තුන්වැන්න එම ගැටළු වලින් අවම වේ. නව සංයෝජක නිර්වචනය කිරීමේ හැකියාව සඳහා ක්‍රමලේඛකයා ආශා කරන එකම සංකීර්ණ කර්තව්‍යයේ රටාවන් ස්වල්පයක් ඇත. මෙය අවශ්‍ය වූ විට, භාෂාව බොහෝ විට සංකීර්ණ වන අතර එය කෙසේ හෝ නිත්‍ය ප්‍රකාශන සමඟ විග්‍රහ නොකළ යුතුය.

එම අවස්ථා සඳහා විසඳුම් තිබේ. වෙනස් මෙහෙයුම් සමූහයක්, බොහෝ විට වෙනස් වාක්‍ය ඛණ්ඩයක් සහ සෑම විටම පාහේ සාමාන්‍ය ප්‍රකාශනවලට වඩා වැඩි විග්‍රහ කිරීමේ බලයක් සහිතව (එනම්, ඒවා සන්දර්භය රහිත භාෂා සමඟ ගනුදෙනු කරයි. එම උප කුලකය). ඉහත විස්තර කර ඇති “වඩා හොඳ ඩීඑස්එල් භාවිතා කරන්න” ප්‍රවේශය සමඟ විග්‍රහ කරන ජනක යන්ත්‍ර තිබේ. සමහර විග්‍රහයන් අතින්, නිසි කේතයකින් ලිවීමේ විකල්පය සෑම විටම පවතී. සරල උප කාර්යයන් සඳහා නිත්‍ය ප්‍රකාශන භාවිතා කිරීම සහ රීජෙක්ස් ආයාචනා කරන කේතයේ ඇති සංකීර්ණ දේ කිරීම පවා ඔබට මිශ්‍ර කර ගැළපේ.

නිත්‍ය ප්‍රකාශන මෙතරම් ජනප්‍රිය වූයේ කෙසේදැයි පැහැදිලි කිරීමට පරිගණකයේ මුල් වසර ගැන මම නොදනිමි. නමුත් ඔවුන් මෙහි නැවතී සිටිනවා. ඔබ බුද්ධිමත්ව භාවිතා කිරීමට ඇති, නැති බව ඥානවන්ත විට ඔවුන් භාවිතා කරන්න.

— ටියුලින්ස් කෝර්ඩෝවා
source

9

I don't know enough about the early years of computing to explain how regular expressions came to be so popular.අපට අනුමාන කිරීම අනතුරුදායක විය හැකිය: මූලික නිත්‍ය ප්‍රකාශන එන්ජිමක් ක්‍රියාත්මක කිරීම ඉතා පහසුය, කාර්යක්ෂම සන්දර්භය රහිත විග්‍රහකයෙකුට වඩා පහසුය.

— biziclop

15

izbiziclop මම මෙම විචල්‍යය අධිතක්සේරු නොකරමි. " තවත් සම්පාදක සම්පාදකයෙකු" ලෙස හැඳින්වීමට තරම් පූර්වගාමීන් සිටි යාක්, 70 දශකයේ මුල් භාගයේ දී නිර්මාණය කරන ලද අතර, ඊට පෙර අනුවාදයක් යුනික්ස් හි ඇතුළත් කරන grepලදී (අනුවාදය 3 එදිරිව අනුවාදය 4).

මට ඉදිරියට යා හැක්කේ විකිපීඩියාවේ මා සොයාගත් දෙයින් පමණි (එබැවින් මම එය 100% ක් විශ්වාස නොකරමි) නමුත් ඒ අනුව yacc1975 දී නිර්මාණය කරන ලද්දේ LALR පාර්සර් පිළිබඳ සමස්ත අදහස (ඒවා ප්‍රායෝගිකව භාවිතා කළ හැකි පළමු පන්තියේ අය අතර වේ) කාරුණික) ආරම්භ වූයේ 1973 දීය. JIT විසින් ප්‍රකාශන (!) සම්පාදනය කරන ලද පළමු රීජෙක්ස් එන්ජින් ක්‍රියාවට නැංවීම 1968 දී ප්‍රකාශයට පත් කරන ලදී. නමුත් ඔබ හරි, එය පැද්දූ දේ කීමට අපහසුය, ඇත්ත වශයෙන්ම රීජෙක්ස් "ගැනීමට පටන් ගත් විට කීමට අපහසුය. අක්‍රීයයි ". සංවර්ධකයින් භාවිතා කළ පෙළ සංස්කාරකවරුන් ඇතුළත් කළ පසු, ඔවුන්ගේ මෘදුකාංගවලද ඒවා භාවිතා කිරීමට ඔවුන්ට අවශ්‍ය යැයි මම සැක කරමි.

— biziclop

1

pm jpmc26 ඔහුගේ පොත වන JavaScript The Good Parts to the Regex Chapter විවෘත කරන්න.

— විශාරද

2

with very few differences between dialectsඑය "ඉතා ස්වල්පයක්" යැයි මම නොකියමි. ඕනෑම පූර්ව නිශ්චිත අක්ෂර පන්තියකට විවිධ උපභාෂා අතර අර්ථ දැක්වීම් කිහිපයක් ඇත. තවද එක් එක් උපභාෂාවට විශේෂිත වූ විග්‍රහයන් ද ඇත.

— nhahtdh

39

Pers තිහාසික ඉදිරිදර්ශනය

සාමාන්‍ය ප්‍රකාශනවල මූලාරම්භය ගැන විකිපීඩියා ලිපිය තරමක් සවිස්තරාත්මක වේ (ක්ලීන්, 1956). මුල් කාරක රීති පමණක් සාපේක්ෂව සරල *, +, ?, |හා ජිනිවා හි (...). එය මිනිස්සු නෙවෙයි (විය හා විධිමත් භාෂා මිනිස්සු නෙවෙයි ගණිතමය අංකන සමග ප්රකාශ කළ නැඹුරු නිසා, හොඳින් කියවිය හැකි වේ, දෙකක් අවශ්යයෙන්ම විරුද්ධ නැත).

පසුව, කාරක රීති හා හැකියාවන් කර්තෘ පරිණාමය හා සමග වර්ධනය වී perl බසට ලං නිර්මාණය මිනිස්සු නෙවෙයි වෙන්න උත්සාහ කරන ලද, ( "පොදු ඉදිකිරීම් කෙටි විය යුතුයි" ). මෙය වාක්‍ය ඛණ්ඩය බොහෝ සංකීර්ණ කර ඇති නමුත් මිනිසුන් දැන් සාමාන්‍ය ප්‍රකාශන වලට හුරුවී ඇති අතර ඒවා ලිවීමට (කියවන්නේ නැතිනම්) හොඳ බව සලකන්න. ඒවා සමහර විට ලිවීමට පමණක් වන බැවින් ඒවා දිගු වන විට ඒවා සාමාන්‍යයෙන් නිවැරදි මෙවලම නොවන බව අඟවයි. නිතිපතා ප්‍රකාශන අපයෝජනයට ලක්වන විට කියවිය නොහැක.

නූල් මත පදනම් වූ නිත්‍ය ප්‍රකාශන වලින් ඔබ්බට

විකල්ප වාක්‍ය ඛණ්ඩ ගැන කතා කරමින්, අපි දැනටමත් පවතින එකක් දෙස බලමු ( cl-ppcre , Common Lisp හි ). ඔබගේ දිගු නිත්‍ය ප්‍රකාශනය ppcre:parse-stringපහත පරිදි විග්‍රහ කළ හැකිය :

(let ((*print-case* :downcase)
      (*print-right-margin* 50))
  (pprint
   (ppcre:parse-string "^(?:([A-Za-z]+):)?(\\/{0,3})(0-9.\\-A-Za-z]+)(?::(\\d+))?(?:\\/([^?#]*))?(?:\\?([^#]*))?(?:#(.*))?$")))

... සහ පහත දැක්වෙන ස්වරූපයෙන් ප්‍රති results ල:

(:sequence :start-anchor
 (:greedy-repetition 0 1
  (:group
   (:sequence
    (:register
     (:greedy-repetition 1 nil
      (:char-class (:range #\A #\Z)
       (:range #\a #\z))))
    #\:)))
 (:register (:greedy-repetition 0 3 #\/))
 (:register
  (:sequence "0-9" :everything "-A-Za-z"
   (:greedy-repetition 1 nil #\])))
 (:greedy-repetition 0 1
  (:group
   (:sequence #\:
    (:register
     (:greedy-repetition 1 nil :digit-class)))))
 (:greedy-repetition 0 1
  (:group
   (:sequence #\/
    (:register
     (:greedy-repetition 0 nil
      (:inverted-char-class #\? #\#))))))
 (:greedy-repetition 0 1
  (:group
   (:sequence #\?
    (:register
     (:greedy-repetition 0 nil
      (:inverted-char-class #\#))))))
 (:greedy-repetition 0 1
  (:group
   (:sequence #\#
    (:register
     (:greedy-repetition 0 nil :everything)))))
 :end-anchor)

මෙම වාක්‍ය ඛණ්ඩය වඩාත් වාචික වන අතර, ඔබ පහත දැක්වෙන අදහස් දෙස බැලුවහොත්, කියවිය යුතු නොවේ. එබැවින් ඔබට අඩු සංයුක්ත වාක්‍ය ඛණ්ඩයක් ඇති බැවින් දේවල් ස්වයංක්‍රීයව පැහැදිලි වනු ඇතැයි නොසිතන්න .

කෙසේ වෙතත්, ඔබ ඔබේ නිත්‍ය ප්‍රකාශන සමඟ කරදර ඇති කිරීමට පටන් ගන්නේ නම්, ඒවා මෙම ආකෘතියට හරවා ගැනීම ඔබේ කේතය තේරුම් ගැනීමට සහ නිදොස් කිරීමට උපකාරී වේ. මෙය නූල් මත පදනම් වූ ආකෘති වලට වඩා එක් වාසියක් වන අතර එහිදී තනි අක්ෂර දෝෂයක් හඳුනා ගැනීම දුෂ්කර විය හැකිය. මෙම වාක්‍ය ඛණ්ඩයේ ඇති ප්‍රධාන වාසිය නම් නූල් මත පදනම් වූ කේතන ක්‍රමයක් වෙනුවට ව්‍යුහාත්මක ආකෘතියක් භාවිතයෙන් නිත්‍ය ප්‍රකාශන හැසිරවීමයි. එමඟින් ඔබේ වැඩසටහනේ වෙනත් ඕනෑම දත්ත ව්‍යුහයක් වැනි ප්‍රකාශන රචනා කිරීමට සහ ගොඩ නැගීමට ඔබට ඉඩ සලසයි . මම ඉහත සින්ටැක්ස් භාවිතා කරන විට, මෙය සාමාන්‍යයෙන් මට කුඩා කොටස් වලින් ප්‍රකාශන තැනීමට අවශ්‍ය නිසාය ( මගේ කෝඩ් ගොල්ෆ් පිළිතුරද බලන්න ). ඔබේ උදාහරණය සඳහා, අපි ¹ ලිවිය හැකිය :

`(:sequence
   :start-anchor
   ,(protocol)
   ,(slashes)
   ,(domain)
   ,(top-level-domain) ... )

නූල් මත පදනම් වූ නිත්‍ය ප්‍රකාශන ද රචනා කළ හැකිය. කෙසේ වෙතත්, විය හැකියි string උපාමාරු සීමාවන් තියෙනවා අවුල් ඇති කේතය (නැති කුරුල්ලන් ලැග සිටින ගැටළු, මෙන් නොව backticks එදිරිව ගැන හිතන්න $(...), ද, පලා චරිත ඔබට හිසරදය දිය හැක bash දී).

ඉහත පෝරමය මඟින් (:regex "string")ආකෘති වලට ඉඩ ලබා දෙන අතර එමඟින් ඔබට ගස් සමඟ දැඩි අංක මිශ්‍ර කළ හැකිය. මේ සියල්ලම IMHO හොඳ කියවීමේ හැකියාව සහ සංයුක්තතාවයට යොමු කරයි; එය ඩෙල්නන් විසින් ප්‍රකාශ කරන ලද ගැටළු තුනට වක්‍රව ආමන්ත්‍රණය කරයි (එනම් සාමාන්‍ය ප්‍රකාශන භාෂාවෙන් නොවේ).

නිගමනය කිරීමට

බොහෝ අරමුණු සඳහා, දැඩි අංකනය ඇත්ත වශයෙන්ම කියවිය හැකිය. පසුගාමී ලුහුබැඳීම් ආදිය සම්බන්ධ දීර් extended අංකන සමඟ කටයුතු කිරීමේදී දුෂ්කරතා ඇති නමුත් ඒවා භාවිතා කිරීම කලාතුරකින් යුක්ති සහගත නොවේ. අනවශ්‍ය ලෙස නිත්‍ය ප්‍රකාශන භාවිතා කිරීම කියවිය නොහැකි ප්‍රකාශන වලට හේතු විය හැක.
නිත්‍ය ප්‍රකාශන නූල් ලෙස කේතනය කිරීම අවශ්‍ය නොවේ. නිත්‍ය ප්‍රකාශන තැනීමට සහ රචනා කිරීමට ඔබට උදව් කළ හැකි පුස්තකාලයක් හෝ මෙවලමක් ඔබ සතුව තිබේ නම්, ඔබ නූල් හැසිරවීම් හා සම්බන්ධ බොහෝ දෝෂ මඟහරවා ගනු ඇත.
විකල්පයක් ලෙස, විධිමත් ව්‍යාකරණ වඩාත් කියවිය හැකි අතර උප ප්‍රකාශන නම් කිරීම හා සාරාංශ කිරීම වඩා හොඳය. පර්යන්ත සාමාන්‍යයෙන් සරල නිත්‍ය ප්‍රකාශන ලෙස ප්‍රකාශ වේ.

1. නිත්‍ය ප්‍රකාශන යෙදුමක නියතයන් වන බැවින් කියවීමේ වේලාවේදී ඔබේ ප්‍රකාශන ගොඩනඟා ගැනීමට ඔබ කැමති විය හැකිය. බලන්න create-scannerසහ load-time-value:

'(:sequence :start-anchor #.(protocol) #.(slashes) ... )

— coredump
source

5

සමහර විට මම සාම්ප්‍රදායික රෙජෙක්ස් සින්ටැක්ස් වලට පුරුදු වී සිටිමි, නමුත් තරමක් එක කියවිය හැකි රේඛා 22 ක් එක රේඛා රීජෙක්ස් වලට වඩා තේරුම් ගැනීමට පහසු යැයි මට විශ්වාස නැත.

3

@ dan1111 "තරමක් හොඳින් කියවිය හැකි" ;-) හරි, නමුත් ඔබ ඇත්තටම දීර්ඝ regex කිරීමට අවශ්ය නම්, එය හැඟීමක් අවධියේ පසුවේ නිර්වචනය කිරීමට, වගේ කරයි digits, identසහ ඔවුන් රචනා. ඔවුන් එය සිදු කරන ආකාරය මා දකින ආකාරයට සාමාන්‍යයෙන් නූල් හැසිරවීම් (සංයුක්ත කිරීම හෝ අන්තර් මැදිහත්වීම) සිදු වේ. \\\\`උදාහරණයක් ලෙස ඉමාක්ස් පැකේජවල සිදුවීම් සොයන්න . Btw එම පලා චරිතයක් වගේ විශේෂ අක්ෂර සඳහා දෙකම භාවිතා වන බැවින්, මෙම වඩාත් නරක අතට ඇත \nහා \"හා regex කාරක රීති සඳහා \(. හොඳ සින්ටැක්ස් සඳහා ලිප්ස් නොවන උදාහරණයක් නම් printf, %dගැටෙන්නේ නැති තැනයි \d.

— coredump

1

අර්ථ දක්වා ඇති අනුකොටස් පිළිබඳ සාධාරණ කරුණක්. එය බොහෝ අර්ථවත් කරයි. වාචික භාවය වැඩිදියුණු කිරීමක් යැයි මට සැකයි. ආරම්භකයින්ට එය පහසු විය හැකිය (වැනි සංකල්ප greedy-repetitionබුද්ධිමත් නොවන අතර තවමත් ඉගෙන ගත යුතුව ඇත). කෙසේ වෙතත්, එය සමස්ත රටාවම දැකීමට හා ග්‍රහණය කර ගැනීමට වඩා අපහසු බැවින් එය විශේෂ experts යින් සඳහා භාවිතාව කැප කරයි.

@ dan1111 වාචික භාවය වැඩිදියුණු කිරීමක් නොවන බව මම එකඟ වෙමි. වැඩිදියුණු කළ හැකි දෙය නම් නූල් වෙනුවට ව්‍යුහගත දත්ත භාවිතා කරමින් රීජෙක්ස් හැසිරවීමයි.

— කෝර්ඩම්ප්

@ dan1111 සමහර විට මම හස්කල් භාවිතයෙන් සංස්කරණයක් යෝජනා කළ යුතුද? පාර්සෙක් එය කරන්නේ පේළි නවයකින් පමණි; එක් ලයිනර් ලෙස :

do {optional (many1 (letter) >> char ':');  choice (map string ["///","//","/",""]); many1 (oneOf "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-."); optional (char ':' >> many1 digit); optional (char '/' >> many (noneOf "?#")); optional (char '?' >> many (noneOf "#")); optional (char '#' >> many (noneOf "\n")); eof}

. ලෙස දිගු සංගීත designating වැනි පේලි කිහිපයක් සමග domainChars = ...හා section start p = optional (char start >> many p)එය ලස්සන සරල බලයි.

— CR Drost

25

රීජෙක්ස් හි ඇති ලොකුම ගැටළුව වන්නේ ඕනෑවට වඩා දැඩි සින්ටැක්ස් නොවේ, එය කුඩා ගොඩනැඟිලි කොටස් වලින් රචනා කරනවා වෙනුවට සංකීර්ණ ප්‍රකාශනයක් තනි ප්‍රකාශනයකින් ප්‍රකාශ කිරීමට උත්සාහ කිරීමයි. මෙය කිසි විටෙකත් විචල්‍යයන් සහ ශ්‍රිත භාවිතා නොකරන ක්‍රමලේඛයට සමාන වන අතර ඒ වෙනුවට ඔබේ කේතය සියල්ලම එකම පේළියකට ඇතුළත් කරන්න.

රීජෙක්ස් බීඑන්එෆ් සමඟ සසඳන්න . එහි වාක්‍ය ඛණ්ඩය රීජෙක්ස් වලට වඩා පිරිසිදු නොවේ, නමුත් එය වෙනස් ආකාරයකින් භාවිතා කරයි. ඔබ සරල නම් කරන ලද සංකේත නිර්වචනය කිරීමෙන් ආරම්භ කර ඔබට ගැලපීමට අවශ්‍ය සම්පූර්ණ රටාව විස්තර කරන සංකේතයකට පැමිණෙන තෙක් ඒවා රචනා කරන්න.

උදාහරණයක් ලෙස rfc3986 හි URI සින්ටැක්ස් දෙස බලන්න :

URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
scheme        = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
hier-part     = "//" authority path-abempty
              / path-absolute
              / path-rootless
              / path-empty
...

නම් කරන ලද උප ප්‍රකාශන කාවැද්දීමට සහාය වන රීජෙක්ස් සින්ටැක්ස් හි ප්‍රභේදයක් භාවිතා කරමින් ඔබට එකම දේ ලිවිය හැකිය.

පුද්ගලිකව මම සිතන්නේ අක්ෂර පංති, සංක්ෂිප්තකරණය, තේරීම හෝ පුනරාවර්තනය වැනි බහුලව භාවිතා වන විශේෂාංග සඳහා සින්ටැක්ස් වැනි දැඩි රීජෙක්ස් එකක් හොඳයි, නමුත් වඩා සංකීර්ණ හා දුර්ලභ ලක්ෂණ සඳහා ඉදිරි වාචික නම් වඩාත් යෝග්‍ය වේ. සාමාන්‍ය ක්‍රමලේඛන වැනි +හෝ ක්‍රියාකරුවන් අප භාවිතා කරන ආකාරය හා බොහෝ දුරට සමාන වන අතර *දුර්ලභ මෙහෙයුම් සඳහා නම් කරන ලද කාර්යයන් වෙත මාරු වේ.

— කේතඉන්චෝස්
source

12

selfDocumentingMethodName () ඊ () ට වඩා බෙහෙවින් හොඳයි

එහෙමද? BEGIN සහ END වලට වඩා බොහෝ භාෂාවන්ට block සහ block බ්ලොක් පරිසීමක ලෙස තිබීමට හේතුවක් තිබේ.

මිනිසුන් ආතතියට කැමතියි, ඔබ වාක්‍ය ඛණ්ඩය දැනගත් පසු කෙටි පාරිභාෂිතය වඩා හොඳය. ඩී (ඉලක්කම් සඳහා) 'ඉලක්කම්' නම් ඔබේ රීජෙක්ස් උදාහරණය සිතන්න. රීජෙක්ස් කියවීමට ඊටත් වඩා භයානක වනු ඇත. ඔබ එය පාලක අක්ෂර සමඟ වඩාත් පහසුවෙන් විග්‍රහ කළ හැකි නම්, එය XML මෙන් පෙනේ. ඔබ වාක්‍ය ඛණ්ඩය දැනගත් පසු මේ දෙකම හොඳ නැත.

ඔබේ ප්‍රශ්නයට නිසි ලෙස පිළිතුරු දීමට නම්, රීජෙක්ස් පැමිණෙන්නේ ආතතිය අනිවාර්ය වූ දිනවල සිට බව ඔබ වටහා ගත යුතුය. 1 MB XML ලේඛනයක් අද විශාල ගනුදෙනුවක් නොවන බව සිතීම පහසුය, නමුත් අපි කතා කරන්නේ 1 MB ඉතා හොඳ වූ දින ගැන ය ඔබේ මුළු ගබඩා ධාරිතාව. එවකට භාවිතා කරන ලද භාෂාවන් ද අඩුවෙන් පැවති අතර රීජෙක්ස් පර්ල් හෝ සී වලින් සැතපුම් මිලියනයක් away තින් නොවේ, එබැවින් වාක්‍ය ඛණ්ඩය ඉගෙනීමට සතුටු වන දවසේ ක්‍රමලේඛකයන්ට සින්ටැක්ස් හුරුපුරුදු වනු ඇත. එබැවින් එය වඩාත් වාචිකව කිරීමට හේතුවක් නොවීය.

— gbjbaanb
source

1

selfDocumentingMethodNameඇත සාමාන්යයෙන් එකඟ වඩා හොඳ විය eක්රමලේඛකයෙක් දෙබස් කවන ශිල්පීනියක සමඟ පෙල නැති නිසා ඇත්තටම කියවීමේ පහසුව හෝ හොඳ ගුණාත්මක කේතය වන්නේ කුමක් අනුව යථාර්ථය . එකඟ වන පුද්ගලයින් වැරදියි, නමුත් එය එසේ ය.

— ලියුෂෙන්කෝ

1

E ලුෂෙන්කෝ: ඔබ කියා සිටින්නේ e()ඊට වඩා හොඳද selfDocumentingMethodName()?

— ජැක් බී

3

Ac ජැක්ස් බී සමහර විට (ගෝලීය නමක් වැනි) නොවේ. නමුත් තදින් විෂය පථයට? පාහේ නිසැකවම. සාම්ප්‍රදායික ප්‍ර wisdom ාවට වඩා බොහෝ විට.

— ලියුෂෙන්කෝ

1

E ලුෂෙන්කෝ: තනි අකුරු ශ්‍රිත නාමයක් වඩා විස්තරාත්මක නමකට වඩා හොඳ නම් සන්දර්භයක් ගැන සිතීම මට අපහසුය. නමුත් මම හිතන්නේ මෙය පිරිසිදු මතයක්.

— ජැක් බී

1

Iles මයිල්ස්රවුට්: උදාහරණය ඇත්ත වශයෙන්ම e()ස්වයං ලේඛන ක්‍රම නාමයකට එදිරිව ය . විස්තරාත්මක ක්‍රම නාමවලට වඩා තනි අකුරු ක්‍රම භාවිතා කිරීම වැඩිදියුණු කිරීමක් වන්නේ කුමන සන්දර්භය තුළද යන්න ඔබට පැහැදිලි කළ හැකිද?

— ජැක් බී

6

රීජෙක්ස් ලෙගෝ කෑලි වගේ. බැලූ බැල්මට, එකිනෙකට වෙනස් හැඩැති ප්ලාස්ටික් කොටස් ඔබට සම්බන්ධ විය හැකිය. ඔබට හැඩගස්වා ගත හැකි විවිධ දේ නොතිබෙනු ඇතැයි ඔබ සිතනු ඇත, නමුත් අනෙක් අය කරන පුදුමාකාර දේවල් ඔබ දකින අතර එය කෙතරම් පුදුමාකාර සෙල්ලම් බඩුවක්දැයි ඔබ කල්පනා කරයි.

රීජෙක්ස් ලෙගෝ කෑලි වගේ. භාවිතා කළ හැකි තර්ක කිහිපයක් ඇති නමුත් ඒවා විවිධ ස්වරූපයෙන් දම්වැලෙන් බැඳීම මගින් විවිධ රීජෙක්ස් රටා මිලියන ගණනක් සෑදෙන අතර ඒවා බොහෝ සංකීර්ණ කාර්යයන් සඳහා භාවිතා කළ හැකිය.

මිනිසුන් කලාතුරකින් රීජෙක්ස් පරාමිතීන් පමණක් භාවිතා කරයි. නූලක දිග පරීක්ෂා කිරීමට හෝ සංඛ්‍යාත්මක කොටස් එයින් වෙන් කිරීමට බොහෝ භාෂාවන් ඔබට කාර්යයන් ඉදිරිපත් කරයි. පෙළ කැපීමට හා ප්‍රතිසංස්කරණය කිරීමට ඔබට නූල් ශ්‍රිත භාවිතා කළ හැකිය. ඉතා නිශ්චිත සංකීර්ණ කාර්යයන් කිරීමට ඔබ සංකීර්ණ ආකෘති භාවිතා කරන විට රීජෙක්ස් වල බලය දක්නට ලැබේ.

SO හි ඔබට දස දහස් ගණනක් රීජෙක්ස් ප්‍රශ්න සොයා ගත හැකි අතර ඒවා කලාතුරකින් අනුපිටපත් ලෙස සලකුණු කර ඇත. එකිනෙකට වඩා බෙහෙවින් වෙනස් විය හැකි අද්විතීය භාවිත අවස්ථා මෙයින් පමණක් පෙන්වයි.

මෙම වෙනස් සුවිශේෂී කාර්යයන් හැසිරවීමට පෙර නිර්වචනය කළ ක්‍රම ඉදිරිපත් කිරීම පහසු නැත. ඔබට එවැනි කාර්යයන් සඳහා නූල් ශ්‍රිත ඇත, නමුත් එම කාර්යයන් ඔබේ විශේෂිත කාර්යයට ප්‍රමාණවත් නොවේ නම්, එය රීජෙක්ස් භාවිතා කිරීමට කාලයයි

— ෆැලන් ඇන්ජල්
source

2

මෙය විභවතාවයට වඩා පුහුණුවීමේ ගැටලුවක් බව මම හඳුනා ගතිමි. නිතිපතා ප්‍රකාශන සෘජුවම සිදුවන විට ගැටළුව සාමාන්‍යයෙන් පැන නගී සංයුක්ත ස්වභාවයක් උපකල්පනය කරනවා වෙනුවට ක්‍රියාත්මක කරන . ඒ හා සමානව, හොඳ ක්‍රමලේඛකයෙකු තම වැඩසටහනේ කාර්යයන් සංක්ෂිප්ත ක්‍රමවලට දිරාපත් කරයි.

උදාහරණයක් ලෙස, යූආර්එල් සඳහා රීජෙක්ස් නූලක් ආසන්න වශයෙන් අඩු කළ හැකිය:

UriRe = [scheme][hier-part][query][fragment]

වෙත:

UriRe = UriSchemeRe + UriHierRe + "(/?|/" + UriQueryRe + UriFragRe + ")"
UriSchemeRe = [scheme]
UriHierRe = [hier-part]
UriQueryRe = [query]
UriFragRe = [fragment]

නිතිපතා ප්‍රකාශන ඉතා සුළු දේවල් වන නමුත් ඒවායේ පෙනෙන සංකීර්ණතාවයට අන්තර්ග්‍රහණය වන අය විසින් ඒවා අපයෝජනයට ලක් වේ. එහි ප්‍රති ing ලයක් ලෙස වාචාල කතා, දිගු කාලීන වටිනාකමක් නොමැති වීම.

— toplel32
source

2

අවාසනාවකට මෙන් බොහෝ ක්‍රමලේඛන භාෂාවලට රීජෙක්ස් රචනා කිරීමට උපකාරී වන ක්‍රියාකාරීත්වය ඇතුළත් නොවන අතර කණ්ඩායම් ග්‍රහණය කර ගන්නා ආකාරය සංයුතියට එතරම් මිත්‍රශීලී නොවේ.

— CodesInChaos

1

වෙනත් භාෂාවන්ට ඔවුන්ගේ “පර්ල් අනුකූල නිත්‍ය ප්‍රකාශනය” ආධාරයෙන් පර්ල් 5 දක්වා අල්ලා ගත යුතුය. Subexpressions යනු රීජෙක්ස් පිරිවිතරයේ සරල නූල් වලට සමාන නොවේ. ග්‍රහණයන් නම් කළ යුතුය, ව්‍යංග අංකනය මත රඳා නොසිට.

— JDługosz

0

@Cmaster පවසන පරිදි, රීජෙක්ස්ප්ස් මුලින් නිර්මාණය කර ඇත්තේ පියාසර කරන විට පමණක් භාවිතා කිරීමට වන අතර රේඛීය ශබ්ද සින්ටැක්ස් තවමත් වඩාත්ම ජනප්‍රිය එකක් වන්නේ විකාර සහගත (හා තරමක් අවපාතයට) ය. මට සිතිය හැකි එකම පැහැදිලි කිරීම් වන්නේ අවස්ථිතිත්වය, මැසොකිස්වාදය හෝ යන්ත්‍රෝපකරණ ඇතුළත් වීමයි (බොහෝ විට යමක් කිරීමට වඩාත්ම සිත්ගන්නා හේතුව 'අවස්ථිති බව' නොවේ ...)

සුදු අවකාශය සහ අදහස් දැක්වීමට ඉඩ දීමෙන් පර්ල් ඒවා වඩාත් කියවිය හැකි කිරීමට තරමක් දුර්වල උත්සාහයක් දරයි, නමුත් දුරස්ථව පරිකල්පනීය කිසිවක් නොකරයි.

තවත් වාක්‍ය ඛණ්ඩ තිබේ. හොඳ එකක් වන්නේ රීජෙක්ස් සඳහා වන scsh සින්ටැක්ස් ය , එය මගේ අත්දැකීම් අනුව රීජෙක්ස් නිපදවන අතර ඒවා ටයිප් කිරීමට පහසුය, නමුත් සත්‍යයෙන් පසුව තවමත් කියවිය හැකිය.

[ scsh වෙනත් හේතු නිසා විශිෂ්ටයි, එයින් එකක් එහි ප්‍රසිද්ධ පිළිගැනීමේ පා text යයි ]

— නෝමන් ග්‍රේ
source

2

පර්ල් 6 කරයි! ව්‍යාකරණ දෙස බලන්න.

— JDługosz

@ JDługosz මට පෙනෙන පරිදි, එය සාමාන්‍ය ප්‍රකාශන සඳහා විකල්ප වාක්‍ය ඛණ්ඩයකට වඩා විග්‍රහ ජනක යන්ත්‍ර සඳහා යාන්ත්‍රණයක් සේ පෙනේ. නමුත් වෙනස සමහර විට ගැඹුරු එකක් නොවේ.

— නෝමන් ග්‍රේ

එය ආදේශකයක් විය හැකි නමුත් එකම බලයකට පමණක් සීමා නොවේ. නවීකරණයේ 1 සිට 1 දක්වා ලිපි හුවමාරුවක් ඇති නමුත් වඩාත් කියවිය හැකි වාක්‍ය ඛණ්ඩයකින් ඔබට රෙජෙප් එකක් පේළිගත ව්‍යාකරණයකට පරිවර්තනය කළ හැකිය. එය ප්‍රවර්ධනය කරන උදාහරණ මුල් පර්ල් එළිදරව්වේ ඇත.

— JDługosz

0

නිත්‍ය ප්‍රකාශන නිර්මාණය කර ඇත්තේ 'සාමාන්‍ය' සහ හැකි තරම් සරල ලෙස බව මම විශ්වාස කරමි, එබැවින් ඒවා ඕනෑම තැනක (දළ වශයෙන්) එකම ආකාරයකින් භාවිතා කළ හැකිය.

ඔබ නිදසුනකට regex.isRange(..).followedBy(..)විශේෂිත ක්‍රමලේඛන භාෂාවක වාක්‍ය ඛණ්ඩයට හා සමහර විට වස්තු-නැඹුරු ශෛලියට (ක්‍රම දාමය) සම්බන්ධ වේ.

උදාහරණයක් ලෙස සී හි මෙම 'රීජෙක්ස්' පෙනුම කෙසේ වේද? කේතය වෙනස් කළ යුතුය.

වඩාත්ම 'සාමාන්‍ය' ප්‍රවේශය වනුයේ සරල සංක්ෂිප්ත භාෂාවක් නිර්වචනය කිරීමයි. එමඟින් වෙනසක් නොමැතිව වෙනත් ඕනෑම භාෂාවකට පහසුවෙන් කාවැද්දිය හැකිය. රීජෙක්ස් යනු එයයි.

— අවිව් කෝන්
source

0

පර්ල්-අනුකූල නිත්‍ය ප්‍රකාශන එන්ජින් බහුලව භාවිතා වන අතර බොහෝ සංස්කාරකවරුන්ට සහ භාෂාවන්ට තේරුම් ගත හැකි දැඩි ප්‍රකාශන වාක්‍ය ඛණ්ඩයක් සපයයි. @ JDługosz අදහස් දැක්වීමේදී පෙන්වා දුන් පරිදි, පර්ල් 6 (පර්ල් 5 හි නව අනුවාදයක් පමණක් නොව, සම්පූර්ණයෙන්ම වෙනස් භාෂාවක්) තනි තනිව නිර්වචනය කරන ලද මූලද්‍රව්‍යයන්ගෙන් ඒවා ගොඩනඟා ගැනීමෙන් නිත්‍ය ප්‍රකාශන වඩාත් කියවිය හැකි කිරීමට උත්සාහ කර ඇත. උදාහරණයක් ලෙස, විකිබුක්ස් වෙතින් URL විග්‍රහ කිරීම සඳහා උදාහරණ ව්‍යාකරණයක් මෙන්න :

grammar URL {
  rule TOP {
    <protocol>'://'<address>
  }
  token protocol {
    'http'|'https'|'ftp'|'file'
  }
  rule address {
    <subdomain>'.'<domain>'.'<tld>
  }
  ...
}

නිත්‍ය ප්‍රකාශනය මේ ආකාරයට බෙදීමෙන් එක් එක් බිටු තනි තනිව නිර්වචනය කිරීමට ඉඩ සලසයි (උදා: domainඅක්ෂර සංඛ්‍යාත්මකව සීමා කිරීම) හෝ උප පංතිය හරහා විස්තාරණය කිරීම (උදා: පමණක් FileURL is URLසීමා protocolවේ "file").

ඉතින්: නැත, නිත්‍ය ප්‍රකාශනවල තදබදය සඳහා තාක්ෂණික හේතුවක් නොමැත, නමුත් ඒවා නිරූපණය කිරීම සඳහා නව, පිරිසිදු හා වඩා කියවිය හැකි ක්‍රම දැනටමත් මෙහි ඇත! එබැවින් මෙම ක්‍ෂේත්‍රයේ නව අදහස් කිහිපයක් අපට දැකගත හැකිය.

— ගෞරව්
source