Code snippets, ideas and events from IT related projects

Cześć,

co do języka komentarzy, to oczywiście może to być polski, możne też być angielski i francuski (ici on parle francais:))), a jak będą w innych językach to nie będę usuwał.

Spotkałem się z tym, iż komentarze pisane po polsku na anglojęzycznych blogach prowadzonych przez Polaków są usuwane — IMHO to niegrzeczne wobec czytelników i jakieś takie infantylne.

Zastanawiałem się, czy zaczynać pisać po angielsku, bo kaleczę ten język, mimo to uznałem, że się to opłaca, gdyż więcej osób będzie mogło go czytać. Kilka razy pisząc z obcokrajowcami, spotkałem się z info, że kod, rysunki wyglądają ciekawie, no ale tekst jest po polsku więc nijak nie wiadomo o czym jest. Dodatkowo niedługo będę się rozglądał za pracą, pewnie gdzieś za granicą i umiejętność wysławiania się w języku pogan muszę ćwiczyć.

Odnośnie ‘above’ to masz rację, zmieniłem szyk akapitów, a nie zaktualizowałem treści, dzięki, poprawione! Dobra dość, o językach ludzi, przejdźmy do języków programistów :)

Co do ilości linii kodu, jak pisałem, w Ruby będzie tego więcej bo nie jest on skończony. Wszytko wyglądało by lepiej, gdyby projektując składnie asemblera myśleć o składni Ruby, w obecnej sytuacji to trochę na siłę jest to zrobione.

Co do generowania kodu z yacc’a to o tym nie wiedziałem, sądziłem, że jeżeli programista chce ściągnąć projektu by go modyfikować, to w to wlicza się modyfikacja plików yacc’a więc ma go zainstalowanego w systemie. Teraz zastanawiam się nad tym.. w sumie racja, ktoś może ściągać projekt by go skompilować i zainstalować — sam często tak robię. Jak będę miał czas/wenę to dodam pliki wynikowe yacc’a do repozytorium. Dzięki za info!

Odnośnie przyjaznego sposobu pisania wyrażeń arytmetycznych to ten, który zaproponowałeś IMHO jest mniej przyjazny od notacji polskiej, gdyż a) programista musi pamiętać, o kolejności wykonywania wyrażeń (komplikuje to też kompilator) b) czasem trzeba dodawać nawiasy, by wymusić kolejność.

Swoją drogą, projektując (o ile można nazwać to projektowaniem) l33tlang poszedłem dalej i nie użyłem +, -, *, tylko ich słowne odpowiedniki, wyjaśnię przy okazji dlaczego tak zrobiłem, bo wcale nie dlatego, by uprościć kompilator :)

Pokaże to na przykładzie Javy: jest metoda realizująca skomplikowane operacje arytmetyczne, nagle okazuje się, że musi działać na liczbach o znacznie większej precyzji albo o większym zakresie. Taką klasę realizującą operacje na dużych/precyzyjnych liczbach można napisać ale wtedy już zapisane operacje trzeba przepisać z formy

a + b

na coś w stylu:

a.add(b)
MyBigNumber.add(a, b)

bo w Javie nie można przeciążać operatorów, kod trzeba przeorać. Uniknąć tego można implementując w języku przeciążanie operatorów lub cały czas pisać tak, jak w drugim przykładzie, traktować operacje matematyczne, porównania jak zwyczajne funkcje (które są od razu zaimplementowane ale prócz tego niczym się nie różnią). Nie chciałem przeciążania operatorów więc wybrałem drugą metodę. Może jest jakaś inna droga? Swoją drogą w l33tlangu dalej nie można przeciążać żadnych funkcji więc to martwa funkcjonalność. EDIT czytam to teraz i sam nie mogę się połapać, w tym, co napisałem, anyway chodziło mi o to, by traktować te funkcje jak każdą inną, więc o zwykłej nazwie i bez dodatkowych opcji.

Kolejny problem, z wbudowywaniem funkcji widać np w Pythonie (nie jestem pewien, lecz chyba w najnowszej wersji już jest to poprawione), otóż ‘print’ jest wbudowany w język, więc nie da się go przeciążyć, np tak by po odpaleniu:

print 22

otrzymalibyśmy na ekranie 22 poprzedzone nazwą usera, z którego konta działa skrypt — tak się nie da, bo to nie jest zwykła funkcja. AFAIK temu też nie można jej używać w lambdach (chociaż nie jestem pewien). Nie chce mi się sprawdzać ale w PHP jest print i echo, jedna z nich jest zwykłą funkcją, druga słowem kluczowym języka, więc nie można jej przeciążyć.

Odnośnie Twojego pierwszego pkt, to jest bardzo ciekawa technika zapisu liczb: http://en.wikipedia.org/wiki/Church_encoding próbowałem się tego nauczyć i wpleść to wpleść w język ale odpuściłem.

Piszesz, dużo o tym, iż l33tlang’a nie można odpalić na urządzeniach osadzonych — to ciekawy temat, tylko, że ciężko się za niego zabrać — trzeba mieć jakieś urządzenie na którym się go będzie odpalało. OK, są emulatory ale fajnie byłoby od czasu do czasu widzieć, jak to działa :)

Myślałem głównie, czy dało by się go odpalić na jakimś routerze albo komórce? Na tym pierwszym nie znam się zupełnie ale tam śmigają jakieś *nixy + można tam coś wgrać. Nie wiem, poszukam info w wolnym czasie. Co do komórek — moja nie ma Javy ;(

Fajnie byłoby też odpalić go na mikroprocesorze, tylko trzeba mieć programator, mój laptop nie ma portu szeregowego/równoległego a by zbudować programator na USB AFAIK trzeba już mieć mikroprocesor do jego (tzn programatora) zbudowania. Kolejną barierą jest też to, że większość softu i manuali jest pod windowsa.

Kompilacja do pliku wykonywalnego również jest bardzo ciekawym zagadnieniem.

Poruszyłeś sporo innych kwestii w komentarzu, postaram się na nie odpisać później.

pozdrawiam

Znowu zegarek zle chodzi, ja to pisze o godzinie 18.03

Cześć,

odnośnie przykładu z programikiem, to IMHO jest to zbyt rzadka sytuacja by na jej podstawie zmieniać kolejność argumentów wyrażeń arytmetycznych (która IMHO taka jaka jest ma swoje plusy).

Wyjść z takiej sytuacji IMHO było by dość sporo, parser, DSL, można by osadzić parser innego języka (python, lua) z zwyczajnym zapisem i z niego pobrać dane. Swoją drogą, programik rysujący funkcje i udostępniający userowi jakieś API (czy jak to nazwać) to też jakaś forma DSL.

“Tak jak wspomniałem milo by było żeby argumenty funkcji nie musiały być koniecznie ewaluowane przy jej wywołaniu, a to implikuje funkcje eval() w języku”

Niekoniecznie, jeżeli funkcja podawana jest bez nawiasów na końcu może być traktowana jako obiekt, jeśli z nawiasami, to jako funkcja do wywołania, np. takie coś:

def foo(a b opr) {
    opr(a b)
}

add(1 3)        # wywoluje funkcje add (wbudowana implementacja)
foo(1 2 add)    # wywoluje funkckje foo, zwrca 3

Implementacja l33tlanga na razie jest bardzo skąpa, polimofizm, domknięcia i inne rzeczy to póki co odległe sprawy. Kiedyś zbierałem informację, jak działa taki język programowania zacząłem wgryzać się też w polimorfizmy, temat na razie zbyt obcy mi by cokolwiek obmyślić sensownego.

“ograniczyl sie tylko do lambda (chyba ze wymysle jak lambda moze byc funkcja). Oj juz wiem, skoro wywolanie funkcji nie ewaluluje parametrow to lambda moze byc funkcja o nieokreslonej liczbie parametrow gdzie kolejne parametry to wyrazenia ktore maja byc w tworzonej funkcji” — pogmatwane, muszę to przemyśleć.

A tak w ogóle to chyba przeniosę repozytorium projektu na jakiś serwis hostujący projekty w rozproszonym systemie kontroli wersji. Często mam wenę, jak jestem offline, no a wtedy nie mogę commitować niczego, muszę się posiłkować robieniem na boku kopii plików, no a później taki wielki commit wysyłać do repozytorium.

Czytałem na blogu google.code, że mają umożliwić dostęp przez rozproszony system, no ale jakoś to ucichło. Szkoda :(

pozdrawiam & dzięki za uwagi

mam 22 lata i jednak to nie znacznik <code> tak ladnie dzialal w Twoich postach :)

Cześć :)

Ja jak najbardziej rozumiem ze funkcja z nawiasami to wywolanie a bez to obiekt, tak jest w C :)

Mi chodzi o takie rzeczy:

defun funkcja (liczba a, wyrazenie b) { ... }

wywołanie:
funkcja(5 + 2, 2 + 2 * 2)

Przy wywołaniu 5 + 2 jest ewaluowane i do funkcji przekazywana jest liczba 7, nastepny parametr nie jest ewaluowany (bo funkcja spodziewa sie wyrazenia) i jak jest potrzeba to sobie je ewaluluje (robi eval(b) ). Dlatego napisalem ze to implikuje funkcje eval(). Jakze fajny bylby jezyk :

defun if(bool warunek, wyrazenie jesli_tak, wyrazenie jesli_nie) {
  return eval(warunek ? jesli_tak : jesli_nie)
}

i od teraz mamy if'a:

if (2 + 2 < 6, say("foo"), say("bar")
; pierwszy argument jest ewaluowany i jest przekazywana prawda/fałsz a kolejne sa przekazywane tak jak byly napisane.

Pseudokod powyzej ma powazny blad logiczny, wiem, to tak zeby zaprezentowac idee.

Wybacz ze tak z lambda zagmatwalem. Wyobraz sobie taka lambde:

funkcja = lambda(tablica typu wyrazenie lista_parametrow, wyrazenie lista_wyrazen, ...)
;zwraca funkcje pobierajaca liste_parametrow i wykonujaca wyrazenia.

np.
add = lambda((wyrazenie []){liczba a, liczba b}, a + b)

add(3, 5) => 8

Eh, i tak mam wrazenie ze niewiele pomogl ten przyklad. A może to ja calkiem nie Cie nie zrozumialem?

Jak juz tak pisze o funkcjach w funkcjach to wiedziales ze w C mozna deklarowac funkcje tak:

int foo(int bar(int, int), int x) { return bar(x, 7L); }

;)

Tak, wlasnie o takie zachowanie jak w haskellu mi chodzi. Calkiem sprytna jest tez symulacja tego w pythonie jaka mi pokazales, z tym ze konieczne jest wywolywanie lambdy, to troche glupipie bo jesli piszemy wlasnego if’a to chodzi o to zeby ewaluowane bylo tylko to co if ma “wykonac”.

W moich przykladach typ “wyrazenie” nie podlegalby ewaluacji przy wywolaniu funkcji, kazdy inny typ (np “liczba”) bylby ewaluowany.

Tablica wyrazenie byla tam po to bo zakladajac ze tworzenie funkcji to tylko wywolanie lambda(), jakos nalezy odroznic parametry tworzonej funkcji od jej ciala — parametry do tablicy a cialo jako reszta parametrow lambdy.

Może ja za nadto komplikuje, ale uwzgledniajac te wymysly mozna zrobic jezyk ktory ma tylko jedna regule: wszystko jest wyrazeniem, tj ciagiem zmiennych lub wywolan funkcji polaczonch operatorami. Zadnych slow kluczowych, zadnych cukrow skladniowych, zadnych wyjatkow w skladni.

Cześć,

Jeszcze odnośnie przeciążania operatorów, to czasem wygląda ono zupełnie nielogicznie, tzn wiedząc, jak działa klasa nijak nie można się domyślić, jak działa taki przeciążany operator, przykładowo (to będzie kontrowersyjny przykład:-)):

#include <iostream>

int main() {
    std::cout << 4;

    int foo = 5;
    std::cin >> foo;
}

No i widząc obiekt klasy do obsługi wyświetlania napisów nijak można się domyślić, że przesuwając go o 4 bity w lewo wyświetlamy te czwórkę na ekranie, zaś w drugiem przypadku, iż przesuwając bitowo o 5 w prawo zapisujemy z STDIN do zmiennej, w której jest ta piątka.

OK, ten kod jest zrozumiały do kogoś, kto się C++ uczył ale to IMHO tylko dla tego, iż takiej obsługi std::cin, std::cout uczy się od początku.

Takie stosowanie przeciążania operatorów IMHO jest nielogiczne i zaciemnia kod.

IMHO przeciążanie jest OK dla bytów matematycznych (bo przeciąża się głównie operacje matematyczne, zależy od języka) jak tablice, wektory, liczby zespolone dla takich bytów powinna być jakaś opcja, by to umożliwić. Ale dla wszystkiego innego (a to wszystkie inne IMHO stanowi większość) nie.

IMHO język poprawnie implementujący przeciążanie operatorów powinien umożliwiać też zmianę ich pierwszeństwa.

Co do l33tlanga, nie podoba mi się jego składnia, IMHO jest zbyt mało ekspresywna, nie ma wsparcia dla lambd i funkcji wyższego rzędu, etc. Chciałbym coś prostego, ekspresywnego, nawet jeśli musiało by być trudniejsze w nauce. Pomyślałem o takiej składni:

require "package name"

mul : a b -> a*b
add : a b -> a+b

print add mul 3 3 mul 2 2

comment "comment here"

u : limit -> map print range 1 limit

To, co jest przed komentarzem to pierwszy przykład, a to, co po nim drugi, ten drugi tworzy obiekt u przyjmujący jeden argument n oraz wypisujący liczby od 1 do n.

IMHO było by też fajnie, gdyby można było wykorzystywać biblioteki napisane w C, zastanawiam się na razie jak.

Było by też fajnie, gdyby język miał budowę modułową, np tak:

• ktoś pisze rozszerzenie języka korzystając z (jakiejś) nomenklatury, to rozszerzeni jest kompilowane do biblioteki, którą można załadować dynamicznie, do tego pisze dokumentację, jak się tej nowe funkcjonalności używa,
• w katalogu projektu jest config, w którym jest lista dynamicznie ładowanych bibliotek, do tego katalog w którym te liby są,
• podczas kompilacji czytany jest config, ładowane te liby i wykorzystywane procedury z nich
• co by nie było w libach i jakie nowe rzeczy nie były by załadowane, kod jest kompilowany do asemblera a później wykonywany przez maszynę wirtualną lub kompilowany do kodu natywnego

To tylko szkic, jednak IMHO w miarę prosto możliwy do osiągnięcia i oferujący sporo możliwości (no i totalnie nieprzenośny). Obmyślając to chciałem, by język sam w sobie był materiałem, a nie zbiorem reguł.

Więcej rzeczy opiszę później. Jak to widzisz(widzicie)?

pozdrawiam

Cześć, W pierwszych akapitach poruszyłeś kwestie przeciążania operatorów i w 100% to co napisałeś pokrywa się z moimi przemyśleniami na ten temat.

Co do prezentowanej składni, to chyba jej do końca nie ogarniam ;)

mul : a b -> a * b  /* to tworzy funkcje/operator który mnoży? ale przecież
już został użyty operator '*' -- rozumiem że takie operatory jak mnożenie muszą być wbudowane */

Rozważając nad składnią uważam że nad każdym pojedynczym elementem należy się zastanowić i rozważyć plusy i minusy. Oczywiście jakieś bardziej ogólne zasady przy jej projektowaniu tęż należy mieć, ja np proponowałbym takie dwa punkty:

• składnia jest czytelna, dla programisty i dla maszyny; dlaczego? bo kod jest pisany dla programisty, ale warto też mieć eval_string() :)
• nie ma dużej liczby cukrów składniowych; dlaczego? po co mi dwie wersje robienia czegoś samego, wole jedna ale porządną.

Właściwie to tak należałoby się wpierw zastanowić jaki/do czego ma być język. :)

Na koniec, nie rozumiem co czyniłoby opisaną przez Ciebie modułową budowę “total nie nieprzenośną”. (poza kompilowaniem do linux-elf ;))