<Placeholder>

<Placeholder>

Hozzászólások

Szerkesztve: 2020. 10. 29., cs – 18:44

VM-only, vagy tud binárist is fordítani? (Vagy ez le volt valahol írva, csak kiszúrta a szemem?)

Sz*rk: Ok, látom, közben hozzáadtad, hogy C++-on keresztül fordít binárist.

Szerkesztve: 2020. 10. 29., cs – 19:23

Gratulálok hozzá, komoly dolog egy normális programozási nyelv kitalálása és implementálása. Egyszer ráveszem magam, de én csak egy történelmi FORTH gépezetet akarok elejétől végéig megalkotni. Remélhetőleg az nem lesz magas léc. :)
Programozási nyelv terén nálam a Rust szemlélete az utóbbi években mindent visz.

Köszönöm, igyekszem a lehető legjobban megvalósítani. A Rust tényleg nagyon hasít és gyorsan fejlődik, kiváló a numerikus feladatokhoz. Az általános feladatok mellett inkább a tudásreprezentációhoz és a hozzá kapcsolódó feldolgozási feladatokhoz szeretném inkább a szoftverem képességeit kidomborítani.

Talán mert fejlődik a világ? :)  A microservices is az ontológia irányába megy, az AI sem csak mélytanulásból áll, az internet is egyre inkább a szemantikus web fele tart. Miért ne lehetne egy új nyelv, ami ötvözi a klasszikus programozást és az új irányokat, technológiákat?

A példák bővülni fognak nemsokára, a WebAssembly portolás kötötte le az energiámat. Eléggé korlátozott verziót tudtam először feltenni, sok minden nem fut még. Ha kiteszek binárist, akkor biztosan kevesebben telepítik, mint amennyien a weboldalt próbálgatják. Első körben nem akartam olyan példát kitenni, ami nem próbálható ki. Kis türelmedet kérném.

Most én vagyok vaksi, vagy az tényleg nincs benne a példakódokban, hogy hogyan kell egy függvény deklarációjában paramétereket megadni?

Az

*entrypoint main ()
{
    //akármi
};

nekem kicsit redundánsnak tűnik, nem elég annyi, hogy:

*entrypoint
{
    //akármi
};

A több fájlban lévő forráskódot hogyan tervezed megoldani? (Tehát mi lesz: import, #include, vagy saját megoldás?)

Egyébként nekem tetszik, gratulálok.

Psszt, elárulom az IP-címemet: 192.168.0.14

Még kevés példa van kint, azok is egyszerűek. A 'Tömb' nevűben van egy függvény deklaráció, lényegében semmi extra nincs benne. A belépési pont neve akkor nem számít, ha csak egy fájlban (vagy stringben, mint a weboldalon) levő dolgot kell végrehajtani. Javítottam a kommentet. Megoldható lett volna, hogy más-más néven az összes példa betöltődik, és a névvel lehet meghívni őket. De így nem kell kitalálni hogy hívják az indítót. Inkább szemantikai jelentősége van, jelenleg annyi a megkötés, hogy érték nélkül kell meghívni az üres belépési pontot. Természetesen az általános típus string tömb (Store::Vector<Data::String>).

A több fájl betöltése elég más, mint a többi nyelvnél. Tárolók (System::Repository) vannak, ezekbe kell betölteni egyenként, vagy akár .zip fájból. A teszt oldalon egy context, egy raktár és egy értelmező van, minden futás után törlődnek. Lehet túlságosan modulárisra sikerült, egy feltöltött raktár futtatható, validálható, módosítható, transzformálható, kereshető, elmenthető, másolható (majdnem mint egy git repó). Egyszerűbb példát tettem fel 'tároló és futtatás' néven.

Valami ilyet tegyél a nyitóba és akkor nincs megállás :)

 

Hello everybody out there writing code -

I'm doing a (free) next gen programming language (just a hobby, won't be big and
professional like C or Java). This has been brewing for a while now, and is starting to get ready.

Sokat nem gondolodtam rajta, írtam ami eszembe jutott. A valóság az, hogy hobbinak indult, nagy lett, használható is, szerintem van jövője, időm most nem sok, másnak lehet, professzionális is lehet még, engem is jobban érdekel ha mást is. Ezt már nehezebb szépen megfogalmazni. De tetszik amit írtál.

Csak a Furornak van egyedül jövője, kár erőlködni....

Hivatásos pitiáner - Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @

Laikusként, miért dupla kettőspont, eggyel nem lehet megoldani?

Store::Vector<Data::String>

Teljen jogos kérdés, szintén soknak gondolom. Viszont az esztétika és az egyértelműség is fontos szempont. Valóban a C++ nyelvből jött az ötlet. Kibővítve a kérdés így hangzik: hogyan lehet az alábbi kódot egyszerűsíteni? Dupla kettőspont helyett lehetne pont (mint a Jávánál), de akkor összefolyik pár dolog és nincs szinkronban a sima kettősponttal. Nekem picit furcsa az egy kettőspont, de még bármin lehet változtatni.

*alias Prefix::Namespace:{workspace}: other;

[std:id="ID"]
*function bool func1 ([std:out] Store::Vector<Data::String> list) {
    :other::Class source;
    list = source.getList();
    *return !list.empty();
};

Csak egy belső munkatér van importálva mindenhol. Jelenleg megoldatlan probléma, hogy a beolvasott kód nem megy át típusellenőrzésen mielőtt a raktárba kerül, csak végrehajtáskor. Kereséskor meg elég költséges megoldás a típusfeloldás, ezért vannak még mindig teljes típusok megadva amiket aliassal lehet egyszerűsíteni.

Szerkesztve: 2020. 10. 31., szo – 16:11

Hogy szemléltessem minek ez a cécó, minek megint egy +1 dolog, mi ez az egész? Kitaláltam egy kissé bugyuta példát. Mit csinál az alábbi C++ kód?

class ZvgT {
    public:
    char* UunuGIitz;
    void Hubtouzh (const char *jHbzztv);
    void loKuHujJju (const char *IJ7zh77);
    void dfnvdH (const char *jEzGFzfbs);
};

int main (int, char*[]) {
    ZvgT Iugz;
    Iugz.Hubtouzh("Ijhuugt2");
    char kiKbgtC[] = {0x32, 0x32, 0x64, 0x32, 0x64, 0x64, 0x32, 0x64};
    Iugz.dfnvdH (kiKbgtC);
    Iugz.loKuHujJju ("lerCOsiiuNjub");
    return 0;
}

Nagyjából ennyit lát a fordító, a hibakereső meg mennyiségi minta hiányában jópár AI dolog.

*triplets {
    ZvgT gfx:type gfx:Class;
    ZvgT::UunuGIitz gfx:type gfx:canvasBuffer;
    ZvgT::UunuGIitz gfx:canvasSize "127x127";
    ZvgT::Hubtouzh procCpp:callType gfx:createCanvas;
    ZvgT::Hubtouzh procCpp:callType gfx:loadBackgroundFromFile;
    ZvgT::Hubtouzh procCpp:callType procCpp:initialization;
    ZvgT::loKuHujJju procCpp:callType gfx:finishCanvas;
    ZvgT::loKuHujJju procCpp:callType gfx:saveCanvasToFile;
    ZvgT::loKuHujJju procCpp:callType procCpp:finalization;
    ZvgT::loKuHujJju procCpp:require procCpp:initializedState;
    ZvgT::dfnvdH procCpp:callType gfx:drawBox;
    ZvgT::dfnvdH procCpp:require procCpp:initializedState;
};

A fentiekkel együtt sokkal világosabb a kép. Van egy egyszerű C++ kódtöredék, meg némi RDF adat. A sorrendiség ellenőrzését is könnyű megoldani. Eddig szépen hangzik. Amikor a fentiekhez hasonlóan egy valós méretű szoftvert kellene ellenőrizni/kiértékelni, akkor jön a komoly fejfájás. Mindegyik általános nyelv nagyon komplex.

C-re gondoltam. Tapasztalatom az, hogy ha valami nem elérhető, akkor az átlag programozó szemet huny az ilyen "apróság" felett, a sérülékenység (hibás számítás lehetősége) pedig szépen megbúvik a kódban.
Legalábbis kevés akarja végigolvasni a stackoverflow oldalon az erről szóló értekezést és megkeresni hogy melyik a legkisebb erőforrás igényű:
    https://stackoverflow.com/questions/199333/how-do-i-detect-unsigned-int…
    https://stackoverflow.com/questions/1815367/catch-and-compute-overflow-…
    ...
 

> Tapasztalatom az, hogy ha valami nem elérhető, akkor az átlag programozó szemet huny az ilyen "apróság" felett, a sérülékenység (hibás számítás lehetősége) pedig szépen megbúvik a kódban.

Ez a programozó hibája és nem a nyelvé. A C-t kár a Rusttal (vagy akár a C++-szal) összehasonlítani, mert olyan, mint ha a szerszámraktárat hasonlítanád össze egy specializált, programozható ipari robottal; a kettő nem ugyanarra való.

A linkeket köszi, majd alaposabban is átnézem őket.

Mert a C nyelv egy lowlevel nyelv, amiben elemi műveletek és komponensek vannak. Ennyi erővel felvehetnénk a C nyelv típusai közé a stringet és a vektort, a műveletek közé meg a konkatenációt és a vektorműveleteket, továbbá az autoallokációt és az objektumorientált programozást is, hiszen ezek sem vennének el a C erényeiből, viszont hozzáadnának. Csak egy a baj: ezen már rég túl vagyunk és a kapott eredményt C++-nak hívják. C++-ban volna (van?) értelme egy ilyen nyelvi megoldásnak, C-ben viszont nincs se értelme, se keresnivalója. Ott, ha ez kell, akkor megírod függvényben.

A baj az, amit a C szabványosításáért felelős testület gondol a C nyelvről. Elég beszédes a wikipedia rész a C18-ról:

It introduces no new language features, only technical corrections, and clarifications to defects in C11.

https://en.wikipedia.org/wiki/C_(programming_language)#C18

Külső könyvtárként még megvalósítható, de már nem várható érdemi bővítés a C nyelvhez. A C23 várható változásai nagyrészt a C++ kompatibilitáshoz köthetőek.

Köszi, ez jó ötlet. Így elsőre a saturation és az assertion (túlcsordulás esetén kivétel) jöhet szóba csoportos műveleteknél, de egy-egy műveletre korlátozva nehezen kivitelezhető jelenleg. Olyan nyelvet igyekszem alkotni, aminek a komplexitását szükség esetén lehet csökkenteni, könnyen lehet keresni, meg transzformálni. Szeretném bevezetni a szemcsézettség fogalmát (complexity level), ahol pont a hasonló részletes dolgok lennének szabályozva.