ZuriHac: პრაქტიკული ფუნქციონალური პროგრამირება

მიმდინარე წლის ივნისში, შვეიცარიის პატარა ქალაქ რაპერსვილში გაიმართა ღონისძიება ე.წ ZuriHac. ამჯერად მან შეკრიბა ხუთასზე მეტი ჰასკელის მოყვარული, დამწყები დაწყებული ენის დამფუძნებელ მამებამდე. მიუხედავად იმისა, რომ ორგანიზატორები ამ ღონისძიებას ჰაკათონს უწოდებენ, ეს არ არის კონფერენცია ან ჰაკათონი კლასიკური გაგებით. მისი ფორმატი განსხვავდება ტრადიციული პროგრამისტებისგან. ZuriHac-ის შესახებ იღბლიანობით გავიგეთ, მივიღეთ მონაწილეობა და ახლა ჩვენ მოვალეობად მიგვაჩნია მოვუყვეთ უჩვეულო აღმოჩენის შესახებ!

ჩვენს შესახებ

ეს სტატია მოამზადეს ნაციონალური კვლევითი უნივერსიტეტის ეკონომიკის უმაღლესი სკოლის - სანქტ-პეტერბურგის პროგრამის „გამოყენებითი მათემატიკა და ინფორმატიკა“ მე-3 კურსის ორმა სტუდენტმა: ვასილი ალფეროვმა და ელიზავეტა ვასილენკომ. ფუნქციური პროგრამირების გატაცება ორივე ჩვენგანისთვის დაიწყო დ.ნ. მოსკვინის ლექციების სერიით უნივერსიტეტის მე-2 კურსზე. ვასილი ამჟამად მონაწილეობს Google Summer of Code პროგრამაში, რომლის ფარგლებშიც იგი ახორციელებს ალგებრულ გრაფიკებს ჰასკელში პროექტის გუნდის ხელმძღვანელობით. ალგა. ელიზავეტამ შეძენილი ფუნქციონალური პროგრამირების უნარები გამოიყენა ანტი-უნიფიკაციის ალგორითმის დანერგვის საკურსო სამუშაოებში, შემდგომი გამოყენებით ტიპების თეორიაში.

ღონისძიების ფორმატი

სამიზნე აუდიტორია არის ღია კოდის პროექტების მფლობელები, პროგრამისტები, რომლებსაც სურთ მონაწილეობა მიიღონ მათ განვითარებაში, ფუნქციონალური პროგრამირების მკვლევარები და უბრალოდ ჰასკელით გატაცებული ადამიანები. წელს, HSR Hochschule für Technik Rapperswil-ის ადგილზე, ორმოცდაათზე მეტი ღია კოდის Haskell პროექტის დეველოპერები შეიკრიბნენ მთელი მსოფლიოდან, რათა ისაუბრონ თავიანთ პროდუქტებზე და ახალი ხალხი დაინტერესდნენ მათი განვითარებით.

ფოტო Twitter-დან ZuriHac

სქემა ძალიან მარტივია: წინასწარ უნდა დაწეროთ რამდენიმე წინადადება თქვენი პროექტის შესახებ და გაუგზავნოთ ორგანიზატორებს, რომლებიც გამოაქვეყნებენ ინფორმაციას თქვენი პროექტის შესახებ ღონისძიების გვერდზე. გარდა ამისა, პირველ დღეს პროექტების ავტორებს აქვთ ოცდაათი წამი, რათა სცენიდან ძალიან მოკლედ თქვან რას აკეთებენ და რა არის გასაკეთებელი. შემდეგ დაინტერესებული პირები ეძებენ ავტორებს და დეტალურად ეკითხებიან ამოცანებს.

ჯერ არ გვაქვს ჩვენი ღია პროექტები, მაგრამ ძალიან გვინდა წვლილი შევიტანოთ არსებულში, ამიტომ დავრეგისტრირდით როგორც რეგულარული მონაწილეები. სამი დღის განმავლობაში ვიმუშავეთ დეველოპერების ორ ჯგუფთან. გამოდის, რომ კოდისა და ცოცხალი კომუნიკაციის ერთობლივი შესწავლა პროექტის ავტორებსა და კონტრიბუტორებს შორის ურთიერთქმედებას ძალიან პროდუქტიულს ხდის - ZuriHac-ში ჩვენ შევძელით გვესმოდეს ის სფეროები, რომლებიც ჩვენთვის ახალი იყო და შევძელით დავეხმაროთ ორ სრულიად განსხვავებულ გუნდს, თითოეულში ერთი დავალების შესრულება. პროექტების.

ღირებული პრაქტიკის გარდა, ZuriHac-ში ჩატარდა რამდენიმე ლექცია და მასტერკლასი. განსაკუთრებით გვახსოვს ორი ლექცია. პირველ მათგანზე, ანდრეი მოხოვმა ნიუკასლის უნივერსიტეტიდან ისაუბრა სელექციურ აპლიკაციურ ფუნქციებზე - ტიპების კლასზე, რომელიც შუალედური უნდა გახდეს აპლიკაციურ ფუნქციებსა და მონადებს შორის. სხვა ლექციაზე, ჰასკელის ერთ-ერთმა დამფუძნებელმა, საიმონ პეიტონ ჯონსმა ისაუბრა იმაზე, თუ როგორ მუშაობს ტიპის დასკვნა GHC კომპილატორში.

საიმონ პეიტონ ჯონსის ლექცია. ფოტო Twitter-დან ZuriHac

ჰაკათონის დროს ჩატარებული მასტერკლასები დაყოფილი იყო სამ კატეგორიად მონაწილეთა მომზადების დონის მიხედვით. ასევე სირთულის დონით აღინიშნა დავალებები, რომლებიც შესთავაზეს მონაწილეებს, რომლებიც შეუერთდნენ პროექტების შემუშავებას. ფუნქციონალური პროგრამისტების პატარა, მაგრამ მეგობრული საზოგადოება სიხარულით მიესალმება ახალწვეულებს თავის რიგებში. თუმცა, ანდრეი მოხოვისა და სიმონ პეიტონ ჯონსის ლექციების გასაგებად, ფუნქციონალური პროგრამირების კურსი, რომელიც ჩვენ უნივერსიტეტში გავიარეთ, ძალიან სასარგებლო იყო.

ღონისძიებაზე რეგისტრაცია უფასოა როგორც რეგულარული მონაწილეებისთვის, ასევე პროექტის ავტორებისთვის. ივნისის დასაწყისში შევიტანეთ განაცხადები მონაწილეობის მისაღებად, რის შემდეგაც სწრაფად გადაგვიყვანეს მოლოდინიდან დადასტურებულ მონაწილეთა სიაში.

ახლა კი ვისაუბრებთ იმ პროექტებზე, რომლებშიც მონაწილეობა მივიღეთ.

პანდოკი

პანდოკი არის ტექსტური დოკუმენტების უნივერსალური გადამყვანი, ფაქტობრივად, ნებისმიერი ფორმატიდან ნებისმიერზე. მაგალითად, docx-დან pdf-მდე, ან Markdown-დან MediaWiki-მდე. მისი ავტორი, ჯონ მაკფარლეინი, არის ფილოსოფიის პროფესორი კალიფორნიის უნივერსიტეტში, ბერკლი. ზოგადად, პანდოკი საკმაოდ ცნობილია და ზოგიერთ ჩვენს მეგობარს გაუკვირდა, როცა გაიგეს, რომ პანდოკი ჰასკელზე იყო დაწერილი.

Pandoc-ის მიერ მხარდაჭერილი დოკუმენტების ფორმატების სია. საიტზე ასევე არის მთელი გრაფიკი, მაგრამ ეს სურათი არ ჯდება სტატიაში.

რა თქმა უნდა, Pandoc არ უზრუნველყოფს პირდაპირ კონვერტაციას ყველა წყვილი ფორმატისთვის. ასეთი მრავალფეროვანი ტრანსფორმაციების მხარდასაჭერად გამოიყენება სტანდარტული არქიტექტურული გადაწყვეტა: ჯერ მთელი დოკუმენტი ითარგმნება სპეციალურ შიდა შუალედურ წარმომადგენლობაში, შემდეგ კი ამ შიდა წარმომადგენლობიდან წარმოიქმნება დოკუმენტი სხვა ფორმატში. დეველოპერები შიდა წარმომადგენლობას უწოდებენ "AST", რომელიც ნიშნავს აბსტრაქტული სინტაქსის ხეს, ან აბსტრაქტული სინტაქსის ხე. თქვენ შეგიძლიათ შეხედოთ შუალედურ წარმოდგენას ძალიან მარტივად: ყველაფერი რაც თქვენ უნდა გააკეთოთ არის გამომავალი ფორმატის დაყენება „მშობლიურად“

$ cat example.html
<h1>Hello, World!</h1>

$ pandoc -f html -t native example.html
[Header 1 ("hello-world",[],[]) [Str "Hello,",Space,Str "World!"]]

მკითხველებს, რომლებიც ცოტათი მაინც მუშაობდნენ ჰასკელთან, უკვე შეუძლიათ ამ მცირე მაგალითიდან ვივარაუდოთ, რომ პანდოკი დაწერილია ჰასკელში: ამ ბრძანების გამომავალი არის პანდოკის შიდა სტრუქტურების სიმებიანი წარმოდგენა, შექმნილი მსგავსებით, თუ როგორ კეთდება ეს ჩვეულებრივ. ჰასკელში, მაგალითად, სტანდარტულ ბიბლიოთეკაში.

ასე რომ, აქ ხედავთ, რომ შიდა წარმოდგენა არის რეკურსიული სტრუქტურა, რომლის თითოეულ შიდა კვანძში არის სია. მაგალითად, ზედა დონეზე არის ერთი ელემენტის სია - პირველი დონის სათაური ატრიბუტებით "hello-world",[],[]. ამ სათაურის შიგნით არის დამალული სტრიქონის სია "Hello", რასაც მოჰყვება ინტერვალი და სტრიქონი "World!".

როგორც ხედავთ, შიდა წარმოდგენა დიდად არ განსხვავდება HTML-ისგან. ეს არის ხე, სადაც თითოეული შიდა კვანძი იძლევა გარკვეულ ინფორმაციას მისი შთამომავლების ფორმატირების შესახებ, ხოლო ფოთლები შეიცავს დოკუმენტის რეალურ შინაარსს.

თუ ჩავალთ განხორციელების დონეზე, მონაცემთა ტიპი მთელი დოკუმენტისთვის ასე განისაზღვრება:

data Pandoc = Pandoc Meta [Block]

აქ ბლოკი არის ზუსტად ზემოთ ნახსენები შიდა წვეროები, ხოლო მეტა არის მეტაინფორმაცია დოკუმენტის შესახებ, როგორიცაა სათაური, შექმნის თარიღი, ავტორები - ეს განსხვავებულია სხვადასხვა ფორმატში და Pandoc ცდილობს, თუ ეს შესაძლებელია, შეინარჩუნოს ასეთი ინფორმაცია ფორმატიდან ფორმატში თარგმნისას. ფორმატი.

Block ტიპის თითქმის ყველა კონსტრუქტორი - მაგალითად, Header ან Para (აბზაცი) - არგუმენტებად იღებს ატრიბუტებს და ქვედა დონის წვეროების ჩამონათვალს - Inline, როგორც წესი. მაგალითად, Space ან Str არის Inline ტიპის კონსტრუქტორები და HTML ტეგი ასევე იქცევა თავის სპეციალურ Inline-ად. ჩვენ ვერ ვხედავთ ამ ტიპების სრული განმარტების მიწოდებას, მაგრამ გაითვალისწინეთ, რომ ის შეგიძლიათ ნახოთ აქ აქ.

საინტერესოა, რომ პანდოკის ტიპი მონოიდურია. ეს ნიშნავს, რომ არსებობს რაიმე სახის ცარიელი დოკუმენტი და ეს დოკუმენტები შეიძლება ერთად იყოს დაწყობილი. ეს მოსახერხებელია Readers-ის წერისას - შეგიძლიათ დაყოთ დოკუმენტი ნაწილებად, თვითნებური ლოგიკის გამოყენებით, თითოეული ცალკე გაანალიზოთ და შემდეგ ყველაფერი ერთად მოათავსოთ ერთ დოკუმენტში. ამ შემთხვევაში მეტაინფორმაცია შეგროვდება დოკუმენტის ყველა ნაწილიდან ერთდროულად.

მაგალითად, LaTeX-დან HTML-ში გადაყვანისას, ჯერ სპეციალური მოდული სახელწოდებით LaTeXReader გარდაქმნის შეყვანის დოკუმენტს AST-ად, შემდეგ სხვა მოდული სახელწოდებით HTMLWriter გარდაქმნის AST-ს HTML-ად. ამ არქიტექტურის წყალობით, არ არის საჭირო კონვერტაციების კვადრატული რაოდენობის დაწერა - საკმარისია ჩაწეროთ Reader და Writer ყოველი ახალი ფორმატისთვის და კონვერტაციის ყველა შესაძლო წყვილი ავტომატურად იქნება მხარდაჭერილი.

ნათელია, რომ ასეთ არქიტექტურას აქვს თავისი ნაკლოვანებებიც, რასაც დიდი ხანია პროგნოზირებდნენ პროგრამული არქიტექტურის დარგის ექსპერტები. ყველაზე მნიშვნელოვანი არის სინტაქსის ხეში ცვლილებების შეტანის ღირებულება. თუ ცვლილება საკმარისად სერიოზულია, თქვენ მოგიწევთ კოდის შეცვლა ყველა Readers და Writer-ში. მაგალითად, ერთ-ერთი გამოწვევა, რომლის წინაშეც დგას Pandoc დეველოპერები, არის რთული ცხრილების ფორმატების მხარდაჭერა. ახლა Pandoc-ს შეუძლია შექმნას მხოლოდ ძალიან მარტივი ცხრილები, სათაურით, სვეტებით და მნიშვნელობით თითოეულ უჯრედში. მაგალითად, HTML-ში colspan ატრიბუტი უბრალოდ იგნორირებული იქნება. ამ ქცევის ერთ-ერთი მიზეზი არის ცხრილების ყველა ან სულ მცირე მრავალ ფორმატში წარმოდგენის ერთიანი სქემის არარსებობა - შესაბამისად, გაურკვეველია, რა ფორმით უნდა იყოს შენახული ცხრილები შიდა წარმომადგენლობაში. მაგრამ კონკრეტული ხედის არჩევის შემდეგაც კი, თქვენ მოგიწევთ შეცვალოთ აბსოლუტურად ყველა Reader და Writer, რომლებიც მხარს უჭერენ ცხრილებთან მუშაობას.

ჰასკელის ენა შეირჩა არა მხოლოდ ავტორების დიდი სიყვარულის გამო ფუნქციონალური პროგრამირებისადმი. Haskell ცნობილია ტექსტის დამუშავების ფართო შესაძლებლობებით. ერთი მაგალითია ბიბლიოთეკა პარსეკი არის ბიბლიოთეკა, რომელიც აქტიურად იყენებს ფუნქციური პროგრამირების ცნებებს - მონოიდები, მონადები, აპლიკაციური და ალტერნატიული ფუნქციები - თვითნებური პარსერების დასაწერად. პარსეკის სრული ძალა ჩანს მაგალითი HaskellWiki-დან, სადაც ხდება მარტივი იმპერატიული პროგრამირების ენის სრული პარსერი. რა თქმა უნდა, Parsec ასევე აქტიურად გამოიყენება Pandoc-ში.

მოკლედ აღწერილია, რომ მონადები გამოიყენება თანმიმდევრული ანალიზისთვის, როდესაც ჯერ ერთი რამ მოდის, შემდეგ კი მეორე. მაგალითად, ამ მაგალითში:

whileParser :: Parser Stmt
whileParser = whiteSpace >> statement

ჯერ უნდა დათვალოთ სივრცე, შემდეგ კი განცხადება - რომელსაც ასევე აქვს Parser Stmt ტიპი.

ალტერნატიული ფუნქციები გამოიყენება უკან დასაბრუნებლად, თუ ანალიზი ვერ ხერხდება. Მაგალითად,

statement :: Parser Stmt
statement = parens statement <|> sequenceOfStmt

ნიშნავს, რომ თქვენ ან უნდა სცადოთ წაიკითხოთ განცხადება ფრჩხილებში, ან შეეცადოთ წაიკითხოთ რამდენიმე განცხადება თანმიმდევრულად.

აპლიკაციური ფუნქციები ძირითადად გამოიყენება მონადების მალსახმობებად. მაგალითად, ნება მიეცით tok ფუნქციას წაიკითხოს ზოგიერთი ნიშანი (ეს არის რეალური ფუნქცია LaTeXReader-ისგან). მოდით შევხედოთ ამ კომბინაციას

const <$> tok <*> tok

ის წაიკითხავს ორ ჟეტონს ზედიზედ და დააბრუნებს პირველს.

ყველა ამ კლასისთვის, ჰასკელს აქვს ლამაზი სიმბოლური ოპერატორები, რაც Reader პროგრამირებას ASCII ხელოვნებას ჰგავს. უბრალოდ აღფრთოვანებული იყავით ამ შესანიშნავი კოდით.

ჩვენი ამოცანები დაკავშირებული იყო LaTeXReader-თან. ვასილის ამოცანა იყო mbox და hbox ბრძანებების მხარდაჭერა, რომლებიც სასარგებლო იყო LaTeX-ში პაკეტების დასაწერად. ელიზაბეთი პასუხისმგებელი იყო ეპიგრაფის ბრძანების მხარდაჭერაზე, რომელიც საშუალებას გაძლევთ შექმნათ ეპიგრაფები LaTeX დოკუმენტებში.

ჰტრაისი

UNIX-ის მსგავსი ოპერაციული სისტემები ხშირად ახორციელებენ ptrace სისტემის ზარს. ის სასარგებლოა პროგრამის გარემოს გამართვისა და სიმულაციისთვის, რაც საშუალებას გაძლევთ თვალყური ადევნოთ სისტემის ზარებს, რომლებსაც პროგრამა აკეთებს. მაგალითად, ძალიან სასარგებლო strace უტილიტა იყენებს ptrace-ს შინაგანად.

Hatrace არის ბიბლიოთეკა, რომელიც უზრუნველყოფს ინტერფეისს ჰასკელში ptrace-ისთვის. ფაქტია, რომ თავად ptrace ძალიან დახვეწილია და მისი უშუალო გამოყენება საკმაოდ რთულია, განსაკუთრებით ფუნქციური ენებიდან.

ჰეთრეისი დაწყებისას სტრეისის მსგავსად მუშაობს და იღებს მსგავს არგუმენტებს. ის განსხვავდება strace-ისგან იმით, რომ ის ასევე არის ბიბლიოთეკა, რომელიც უზრუნველყოფს უფრო მარტივ ინტერფეისს, ვიდრე უბრალოდ ptrace.

ჰეთრეისის დახმარებით, ჩვენ უკვე დავიჭირეთ ერთი უსიამოვნო შეცდომა GHC Haskell-ის შემდგენელში - არასწორ მომენტში მოკვლა, ის ქმნის არასწორ ობიექტურ ფაილებს და ხელახლა არ აწყობს მათ გადატვირთვისას. სისტემური ზარების სკრიპტირებამ შესაძლებელი გახადა შეცდომის საიმედოდ რეპროდუცირება ერთ გაშვებაში, ხოლო შემთხვევითი მოკვლა შეცდომის რეპროდუცირებას ახდენდა დაახლოებით ორ საათში.

ბიბლიოთეკას დავამატეთ სისტემური ზარის ინტერფეისები - ელიზავეტამ დაამატა brk, ხოლო ვასილიმ დაამატა mmap. ჩვენი მუშაობის შედეგებიდან გამომდინარე, ბიბლიოთეკის გამოყენებისას შესაძლებელია ამ სისტემური ზარების არგუმენტების გამოყენება უფრო მარტივად და ზუსტად.

წყარო: www.habr.com