Létezik olyan programnyelv, amiben nincsenek méretkorlátok, változo darabszám, string hossz szám, tömb méret és dimenszioszám, stb korlátok, hanem csak az aktuális memoria szab ennek határt?

A változók darabszámát a stack mérete korlátozza, nem a teljes szabad memória... de mért akarna valaki milliószám lokális változókat használni? El.életi kérdésnek oké, de gyakorlatban már 100-as nagyságrendű lokális változó is sok.

Persze a string és tömb méretre (ami kb ugyanaz) már nem vonatkozik a fenti. Persze ott is szoktak korlátok lenni, hogy pl egy tömb-öt egy (előjeles) 32 bites számmal tudsz indexelni, így max 2 milliárd eleme lehet, ami ha 64 bites számokat tartalmaz csak 16GB.

"de mért akarna valaki milliószám lokális változókat használni?"

Nem csak az használhatja a stacket, hanem van lehetőség a c-szerű nyelvekben a stacken létrehozni tömböt, például

String myArray[100000000000];

Ez lehetséges hiba a programozó részéről, hogyha nem figyel

(ha nem stackre akarná, akkor valahogy így kéne:

String myArray[] = new String[100000000000]; )

(csak hogy érezni lehessen a különbséget)

Utólag is bocsi, ha syntax hibás, én C nyelvet használok, ott meg a malloc kicsit máshogy működik, mint a new konstruktorral!

"hol van a kérdésben "lokális változóról" szó"

Hát, nekem a változó az lokális változó. OOP esetén ami az osztályban van, az már nem változó, hanem mező...de bocs, ha félreértettem, és a kérdező nem a lokális változókra gondolt.

"És nem egy esetben lehet szükség igen nagy számú változóra egy programban": tehát millió saját névvel rendelkező változóra? Nem tömbökre (akár stacken, akár heam-en lévő) gondolok. Szerintem ha milliós számú változóra van szükség, akkor ott valami nincs rendben a kóddal.

Rekurzív függvények esetében is azthiszem sok lokális változó vagy argumentum kerül a verembe. Ha ezt nézzük, akkor a Haskell az, amely erősen optimalizálva van arra, hogy a stack kezelésére ne legyen érzékeny, és olyan rekurzív függvények is bátran használhatóak, amelyeket más nyelveken nem szokás, akár egész szövegfájlok betűnként feldolgozása is lehetséges tisztán rekurzív függvényekkel.

Emellett meg Haskellben az Integer típusnak nincsméretkorlátja, akár több képernyőt elfoglaló óriásszámokat is képes ábrázolni. Azonban a lebegőpontos típusok ott is méretkorlátosak, most eltekintve valami speciális könyvtárak szolgáltatásaitól.

A tömbök kérdése egy kicsit összetettebb, azokhoz nem is annyira értek, de úgy tudom, hogy alacsonyszintű, a hardware adottságokat közvetlenül kihsználó tömb nem létezik ott, vagy speckó könyvtárakból lehet csak elérni, helyette mindenféle keresőfás trükköt használnak.

Agda nyelven pedig a típusok elmélete teljesen összefolyik az elsőrendű predikátumkalkulussal (Curry-Howard megfeleltetés), ebben az értelemben ott nem afféle előre beégetett korlátokkal találkozik az ember, hanem maga az alapelmélet az, ami eléggé sok tanulást igényel (Martin-Löf típuselmélet), cserébe az ember viszont nagyfokú rugalmasságot és típusbiztonságot kap, sőt, akár teljesen életszerű és akár ipari jellegű matematikai tételbizonyításokara is felhasználhatja a fordítót. Az Agda viszont formálisan nem Turing teljes, mégha az Ackermann-függvény bele is fér még a lehetőségeibe (esetleg tartalmaz még ezenfelül escape lehetőségeket, természetesen a megfelelő típusbiztonsággal ellátva)

Mondhatnám (kicsit tréfásan): az Assembly a te nyelved... Abban semmire sincs semmi korlát a hardveren kívül (bele értve a processzor képességeit és a hardver képességeit).

Amit 7-es írt (2023.02.15. 08:32) erősen elgondolkodtató (öv. a korábbiakkal). Illetve az egész OOP nem OOP, C (és klónjai) nem C, python és társai kérdésköröktől ez nem elválasztható.

Tudjuk a C még úgy-ahogy de a klónjai (és gyermekei) illetve az egész OOP nem arról szól, hogy az a hardvernek jó legyen (ld. 7.). Eleve ez a "korlátlan stack mánia" (értem én, hogy C és így találták ki és ma már kvázi végtelen a memória) lassít nem keveset hanem sokat. Világos az üzenet, több kérdésnél ki lett részletesen elemezve, hogy az OOP világ és a "korszerű" nyelvek azt segítik, hogy a programozónak (és ide értve a tesztelőket is) könnyebb legyen a dolguk, kevesebb időráfordítással gyorsabban tudjanak programot írni. Ehhez ma már vannak irtózatos kapacítású gépek. Nyilván összevetve egy Cobollal (bár abban a kötelező 2 v. 3 feladaton kívül többet nem programoztam) vagy egy Fortrannal (de még ide vehetjük a Pascal-t is, bár az már kicsit más) egészen más elképzelések vannak nyelv szintjén a változó kezelésről, a tömbökről, és egészen mások egy függvényhívásnál az értékátadásról. Pl. érdemes megnézni akár a korabeli nagygépeket (IBM360,370, 390) nem volt bennük a "kisgépes" világnak megfelelő stack egyáltalán (ott más módon oldották meg a függvényhívást és a függvények reenterelését is) mint pl. PDP 11 sorozatnál. Itt azért érdemes egy kicsit "megállni" és ezeket nézni, mert a C (és a unix) alapvetően PDP 11-re készült, és rengeteg jellemzője visszaköszön a PDP 11 adottságaiban. Tudom most ez sokaknak kiakasztó, de a mai napig egy 50 évvel ezelőtti gép adottságai alapján programozunk? Fura de igen. Volt egy külföldi fórumon egy vitám egy fószerrel, és ott átküldte, hogy olvassam el a PDP 11 dokumentációját és utána vitatkozzak vele. És valóban érdekes olvasmány volt, és egy rakás dolgot amit nem igazán értettem a C-ben világossá vált, hogy jahh mert a PDP 11 így támogatta. Érdemes egyébként elolvasni mert nagyon tanulságos iromány.

Visszatérve a kérdésre: változó darabszámra nem igazán van korlát a legtöbb nyelvben csak a memória. Már a legelső nyelvek esetén is 6 karakter volt a változónév (ld. pl. Fortran66) ebből az elsőnek kellett csak betűnek lennie a többi lehett szám, ha nem case sensitive a változónév akkor 6 karakteren is a fenti szabály szerint 26*36^5 eltérő változónevet lehet alkotni (Ez kb. 8*10^38 db. változónév, azért ennek elégnek kell lennie, mert ennyi memória sem nagyon van...). A tömb méret korlát meg inkább implementáció függő. A hardverben kb. az szab korlátot, hogy az indexelt vagy. inderekt címzés esetén mekkora lehet a címzéshez használt regiszter hossza ez pl.az x86 világban most 64 bit. A zSeries-ben nem emlékszem, régen olvastam ennek utána, hogy ott mennyi, most nincs kedvem kibányászni a doksiból. ARM családnál is a teljes memória kicímezhető regiszteren keresztül, ott sincs hardver korlátja a tömb méretnek.