Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Coati 09. 09. 2022, 09:09:11
-
Doufám, že tu jsou nějací fortranisti :) Má moderní Fortran něco jak trait v Rustu? Podle dokumentace k F2018 jsem to v jeho OO vlastnostech nenašel, ale vzhledem k rozsahu se to dá snadno přehlédnout.
-
Ne nemá, ale tady je proposal a konverzace dvou zasvěcených Fortranistů. https://github.com/j3-fortran/fortran_proposals/issues/125
-
Ne nemá, ale tady je proposal a konverzace dvou zasvěcených Fortranistů. https://github.com/j3-fortran/fortran_proposals/issues/125
Nějak se jim ta diskuse zvrtla, jeden o voze, druhý o koze. Ale ten původní návrh je dobrý. A ten druhý se statickým polymorfismem taky, hezky se doplňuje. Jsou velice blízko k objevení (typového systému) Go :)
-
Fortran ma moduly. Funkcie z jedneho modulu sa mozu vzajomne volat. Jeden modul moze pouzivat ine moduly a volat z nich funkcie.
-
S pouzitim modulov som to myslel takto:
modules.f95
module tmp_mod1
contains
subroutine t11
write(*, *) "t11"
end subroutine
subroutine t12
write(*, *) "t12 calls:"
call t11
end subroutine
end module tmp_mod1
module tmp_mod2
contains
subroutine t2
write(*, *) "t2"
end subroutine
end module tmp_mod2
module my_mod
use tmp_mod1
use tmp_mod2
contains
subroutine s
write(*, *) "s calls:"
call t11
call t12
call t2
end subroutine
end module my_mod
program main
use my_mod
write(*, *) "main calls:"
call t11
call t12
call t2
call s
end program main
Output:
$ gfortran modules.f95 -o modules
$ modules
main calls:
t11
t12 calls:
t11
t2
s calls:
t11
t12 calls:
t11
t2
-
S pouzitim modulov som to myslel takto:
modules.f95
module tmp_mod1
contains
subroutine t11
write(*, *) "t11"
end subroutine
subroutine t12
write(*, *) "t12 calls:"
call t11
end subroutine
end module tmp_mod1
module tmp_mod2
contains
subroutine t2
write(*, *) "t2"
end subroutine
end module tmp_mod2
module my_mod
use tmp_mod1
use tmp_mod2
contains
subroutine s
write(*, *) "s calls:"
call t11
call t12
call t2
end subroutine
end module my_mod
program main
use my_mod
write(*, *) "main calls:"
call t11
call t12
call t2
call s
end program main
Output:
$ gfortran modules.f95 -o modules
$ modules
main calls:
t11
t12 calls:
t11
t2
s calls:
t11
t12 calls:
t11
t2
Jak to souvisí s traity?
-
něco jak trait v Rustu
Fortran má INTERFACE pro statický ad-hoc polymorfismus, rozhraní jako typ s dynamickým dispatchem ne. Ten výše odkazovaný navrh je pěkný. Ono to jde ve Fortranu s jeho OOP jednoduše obejít, ale je to hnusný kód navíc. Ve Fortranu se naštěstí “populární” OOP nijak moc nepoužívá, případy dědičnosti by člověk spočítal na prstech jedné stonožky. Hezčí řešení přinesou šablony s restrikcemi, k tomu už existuje oficiální návrh.
-
S pouzitim modulov som to myslel takto:
modules.f95
module tmp_mod1
contains
subroutine t11
write(*, *) "t11"
end subroutine
subroutine t12
write(*, *) "t12 calls:"
call t11
end subroutine
end module tmp_mod1
module tmp_mod2
contains
subroutine t2
write(*, *) "t2"
end subroutine
end module tmp_mod2
module my_mod
use tmp_mod1
use tmp_mod2
contains
subroutine s
write(*, *) "s calls:"
call t11
call t12
call t2
end subroutine
end module my_mod
program main
use my_mod
write(*, *) "main calls:"
call t11
call t12
call t2
call s
end program main
Output:
$ gfortran modules.f95 -o modules
$ modules
main calls:
t11
t12 calls:
t11
t2
s calls:
t11
t12 calls:
t11
t2
Jak to souvisí s traity?
Moduly vo fortrane (90+) maju podobny ucel ako traity v inych jazykoch. Sluzia na organizaciu a znovupouzitie kodu.
-
Moduly vo fortrane (90+) maju podobny ucel ako traity v inych jazykoch. Sluzia na organizaciu a znovupouzitie kodu.
Možná jsem něco nepochopil, ale co jsi demonstroval ve svém příkladu, jsou funkce uspořádané do nějakých namespaces. Traity slouží k implementaci nějakého rozhraní napříč různými typy (třídami). Možná tam někde nějaký průnik vidíš, ale nepřijde mi, že by tam byla nějaká zásadní podobnost nebo zastupitelnost.
-
Moduly vo fortrane (90+) maju podobny ucel ako traity v inych jazykoch. Sluzia na organizaciu a znovupouzitie kodu.
Možná jsem něco nepochopil, ale co jsi demonstroval ve svém příkladu, jsou funkce uspořádané do nějakých namespaces. Traity slouží k implementaci nějakého rozhraní napříč různými typy (třídami). Možná tam někde nějaký průnik vidíš, ale nepřijde mi, že by tam byla nějaká zásadní podobnost nebo zastupitelnost.
No ano, OP sa pytal ci Má moderní Fortran něco jak trait v Rustu, ale nepovedal nam na co to vlastne potrebuje, co potrebuje docielit. Fortran nie moc OOP, takze take veci zatial nema ale myslim si, ze na docielenie podobnych veci ako sa robia s pouzitim traitu v inych jazykoch by mohol vo fortrane pouzit akurat tak tie moduly.
-
Moduly vo fortrane (90+) maju podobny ucel ako traity v inych jazykoch. Sluzia na organizaciu a znovupouzitie kodu.
Možná jsem něco nepochopil, ale co jsi demonstroval ve svém příkladu, jsou funkce uspořádané do nějakých namespaces. Traity slouží k implementaci nějakého rozhraní napříč různými typy (třídami). Možná tam někde nějaký průnik vidíš, ale nepřijde mi, že by tam byla nějaká zásadní podobnost nebo zastupitelnost.
Žádný průnik tam není.
-
Fortran nie moc OOP
Fortran je naopak až moc OOP, včetně abstraktních typů a dědičnosti, což třeba Rust nebo Go nemají. Ty traity se dají udělat syntaktickou omáčkou (pokud nestačí INTERFACE), Rust (a Go) je implementují naprosto stejně jako tlusté ukazatele, akorát to dělá transparentně překladač, takže je kód čitelnější.
-
Pokud někdo chce vidět pseudo-OOP prasokód ve Fortranu, tak tady je ukázková otřesnost: https://github.com/LadaF/Fortran-RefCount
-
Ty traity se dají udělat syntaktickou omáčkou
Tak preco neurobis syntaktickou omáčkou male demo traitu vo fortrane ?
Nech je to funkcne, da sa skompilovat v gfortrane a ma zmysluplne pouzitie ..
-
nechapu proc to cpou do fortranu, ten jsem pouzival jen na vypocty a stacily realna cisla, na co dalsi typy.
-
nechapu proc to cpou do fortranu, ten jsem pouzival jen na vypocty a stacily realna cisla, na co dalsi typy.
Tak uživatelské typy se hodí pro lepší reprezentaci kdejakých objektů (například kvaternionů), tím spíš že Fortran má pěkně udělané přetěžování operátorů (a definici vlastních). Méně užitečné je až to OOP à la Java (dynamický dispatch je fajn, ale jde udělat i bez dědičnosti). Navíc se zavedením pointerů Fortran “dostal” typovou nebezpečnost, člověk si musí paměť spravovat manuálně (nebo pointery nepoužívat). K jakým hrůzám to vede ukazuje výše odkazovaný prasokód.
-
Tak preco neurobis syntaktickou omáčkou male demo traitu vo fortrane ?
Nech je to funkcne, da sa skompilovat v gfortrane a ma zmysluplne pouzitie ..
Protože to nepotřebuju a navíc to je triviální a úplně stejné jako třeba v Javě bez rozhraní (její úplně prvotní verze, asi ještě pre-v1.0, je ostatně neměla). Napsat něco jako rustí std::io::Read nebo io.Reader (Go) bez použití traitů/rozhraní a bez vícenásobné dědičnosti bývá oblíbená otázka u zkoušek z úvodu do “OOP”.
-
Moduly vo fortrane (90+) maju podobny ucel ako traity v inych jazykoch. Sluzia na organizaciu a znovupouzitie kodu.
Možná jsem něco nepochopil, ale co jsi demonstroval ve svém příkladu, jsou funkce uspořádané do nějakých namespaces. Traity slouží k implementaci nějakého rozhraní napříč různými typy (třídami). Možná tam někde nějaký průnik vidíš, ale nepřijde mi, že by tam byla nějaká zásadní podobnost nebo zastupitelnost.
Žádný průnik tam není.
Ale je tam analogia - pozri:
class Main implements my_mod {
static void main(String[] args) {
Main m = new Main();
println("main calls:")
m.t11()
m.t12()
m.t2()
m.s()
}
}
trait tmp_mod1 {
void t11() {
println("t11");
}
void t12() {
println("t12 calls:")
t11()
}
}
trait tmp_mod2 {
void t2() {
println("t2")
}
}
trait my_mod implements tmp_mod1, tmp_mod2 {
void s() {
println("s calls:")
t11()
t12()
t2()
}
}
output:
main calls:
t11
t12 calls:
t11
t2
s calls:
t11
t12 calls:
t11
t2
-
Moduly vo fortrane (90+) maju podobny ucel ako traity v inych jazykoch. Sluzia na organizaciu a znovupouzitie kodu.
Možná jsem něco nepochopil, ale co jsi demonstroval ve svém příkladu, jsou funkce uspořádané do nějakých namespaces. Traity slouží k implementaci nějakého rozhraní napříč různými typy (třídami). Možná tam někde nějaký průnik vidíš, ale nepřijde mi, že by tam byla nějaká zásadní podobnost nebo zastupitelnost.
Žádný průnik tam není.
Ale je tam analogia - pozri:
class Main implements my_mod {
static void main(String[] args) {
Main m = new Main();
println("main calls:")
m.t11()
m.t12()
m.t2()
m.s()
}
}
trait tmp_mod1 {
void t11() {
println("t11");
}
void t12() {
println("t12 calls:")
t11()
}
}
trait tmp_mod2 {
void t2() {
println("t2")
}
}
trait my_mod implements tmp_mod1, tmp_mod2 {
void s() {
println("s calls:")
t11()
t12()
t2()
}
}
output:
main calls:
t11
t12 calls:
t11
t2
s calls:
t11
t12 calls:
t11
t2
Úžasné!
Teď vážně, jak se tedy ve Fortranu pomocí modulů docílí toho, abych mohl mít funkci, třeba ReadAll, která bude typově bezpečná a bude umět číst data ze souboru, socketu a čehokoliv, co implementuje předem daný protokol (s chybami typové kontroly hlášenými během překladu, ne běhu)?
-
Tak preco neurobis syntaktickou omáčkou male demo traitu vo fortrane ?
Nech je to funkcne, da sa skompilovat v gfortrane a ma zmysluplne pouzitie ..
Protože to nepotřebuju a navíc to je triviální a úplně stejné jako třeba v Javě bez rozhraní (její úplně prvotní verze, asi ještě pre-v1.0, je ostatně neměla). Napsat něco jako rustí std::io::Read nebo io.Reader (Go) bez použití traitů/rozhraní a bez vícenásobné dědičnosti bývá oblíbená otázka u zkoušek z úvodu do “OOP”.
No to som trochu sklamany, myslel som ze ked je to pre Teba trivialne, tak sem das aspon nejaky kusok fungujuceho kodu, aby sa aj ostatni od teba nieco priucili. Ja som sem dal 2 analogicke priklady:
1) s pouzitim modulov vo fortrane
2) s pouzitim traitov v jave (s trochou syntaktickeho cukru)
-
No to som trochu sklamany
To mě mrzí. Slibuji, že až bude chvilka času, nainstaluju si GNU Fortran a napíšu příklad. Ovšem vzhledem k charakteru OOP ve Fortranu ten kód bude hnusný a jako příklad spíše negativní :)
-
No to som trochu sklamany
To mě mrzí. Slibuji, že až bude chvilka času, nainstaluju si GNU Fortran a napíšu příklad. Ovšem vzhledem k charakteru OOP ve Fortranu ten kód bude hnusný a jako příklad spíše negativní :)
;D tak to radsej ani nedavaj.
Uzavrime tuto diskusiu s tym, ze na podobny ucel, na ktory sa pouzivaju v inych jazykoch traity sa vo fortrane daju pouzit moduly.
-
Uzavrime tuto diskusiu s tym, ze na podobny ucel, na ktory sa pouzivaju v inych jazykoch traity sa vo fortrane daju pouzit moduly.
Jenže to není pravda ani trochu, viz co psal Ink. Moduly jsou jen jmenné prostory a nijak nesouvisí s OOP/dynamicitou. Ale uzavřít to můžeme :)
-
veortranu bych ocekaval praci s vektory, maticemi, na co specialni typ pro kvaterniony.
-
veortranu bych ocekaval praci s vektory, maticemi, na co specialni typ pro kvaterniony.
fortran to umoznuje
-
veortranu bych ocekaval praci s vektory, maticemi, na co specialni typ pro kvaterniony.
fortran to umoznuje
proto to pisu, ze fortran je na numeriku a traits a oop jsou v nem zbytecne.
-
veortranu bych ocekaval praci s vektory, maticemi, na co specialni typ pro kvaterniony.
fortran to umoznuje
proto to pisu, ze fortran je na numeriku a traits a oop jsou v nem zbytecne.
suhlasim s tebou na 100%, ze OOP je vo fortrane zbytocne
-
veortranu bych ocekaval praci s vektory, maticemi, na co specialni typ pro kvaterniony.
To tam je, ale někdy se hodí vektor nebo matice kvaternionů (nebo nějakého jiného složitějšího typu).
-
fortran je na numeriku a traits a oop jsou v nem zbytecne.
Co jsem to tak jedním okem sledoval, fortranisti si prostě stěžovali: “Všechny jazyky mají OOP, proč my ne?!” Tak se ustanovil výbor a vznikla verze Fortranu s OOP. To se pak začalo používat. Konzervativní fyzici pořád píšou stylem F77 a nějaké OOP mají někde :)
Úplně stejně to bylo s Prologem, taky vznikla jeho OO verze jen proto, že tehdy to byl buzzword. Už si přesně nevybavuju, který manažer IBM to bez obalu takto přiznal.
-
ja bych si furt myslel, ze na numericke pocitani ol'good fortran a jeste mpi na cluster.
-
ja bych si furt myslel, ze na numericke pocitani ol'good fortran a jeste mpi na cluster.
Pro paralelní zpracování (HPC clustery) má pěkná rozšíření Fortran 2018.
-
Tak s tymi Quaternionmi to samozrejme vo Fortrane ide.
Nadefinujes si vlastny typ Queternion a k nemu overloadujes operatory + - *
To sa urobi zase cez moduly 8), ziadne traity nie su treba.
-
Napriklad, takto to funguje s tymi quaternionmi:
quaternions.f95
module my_quaternions
type quaternion
real :: x, y, z, t
end type quaternion
interface assignment(=)
module procedure quaternion_from_array
end interface
interface operator(+)
module procedure add_quaternions
end interface
interface operator(-)
module procedure substract_quaternions
end interface
interface operator(*)
module procedure hamilton_product
end interface
contains
subroutine quaternion_from_array(q, v)
! construct quaternion Q from an array V
! Q = V
real, dimension(4), intent(in) :: v
type(quaternion), intent(out) :: q
q%x = v(1)
q%y = v(2)
q%z = v(3)
q%t = v(4)
end subroutine quaternion_from_array
subroutine print_quaternion(q, q_name)
type(quaternion), intent(in) :: q
character(*), intent(in) :: q_name
write (*, 10) q_name,' = (', q%x, ', ', q%y, ', ', q%z, ', ', q%t, ')'
write (*,*)
10 format(a, a, f8.2, a, f8.2, a, f8.2, a, f8.2, a)
end subroutine print_quaternion
function add_quaternions(a, b) result(c)
type(quaternion), intent(in) :: a
type(quaternion), intent(in) :: b
type(quaternion) :: c
c%x = a%x + b%x
c%y = a%y + b%y
c%z = a%z + b%z
c%t = a%t + b%t
end function add_quaternions
function substract_quaternions(a, b) result(c)
type(quaternion), intent(in) :: a, b
type(quaternion) :: c
c%x = a%x - b%x
c%y = a%y - b%y
c%z = a%z - b%z
c%t = a%t - b%t
end function substract_quaternions
function hamilton_product(a, b) result(c)
type(quaternion), intent(in) :: a, b
type(quaternion) :: c
c%x = a%x*b%x - a%y*b%y - a%z*b%z - a%t*b%t
c%y = a%x*b%y + a%y*b%x + a%z*b%t - a%t*b%z
c%z = a%x*b%z - a%y*b%t + a%z*b%x - a%t*b%y
c%t = a%x*b%t + a%y*b%z - a%z*b%y + a%t*b%x
end function hamilton_product
end module my_quaternions
program quaternions
use my_quaternions
type(quaternion) :: a, b, c
write (*,'(a)') 'Quaternions example:'
b = (/1., 2., 3., 4./)
a = (/5., 6., 7., 8./)
call print_quaternion(a, 'a')
call print_quaternion(b, 'b')
write (*,'(a)') 'c = a + b'
c = a + b
call print_quaternion(c, 'c')
write (*,'(a)') 'c = a - b'
c = a - b
call print_quaternion(c, 'c')
write (*,'(a)') 'c = a * b'
c = a * b
call print_quaternion(c, 'c')
end program quaternions
Output:
$ gfortran quaternions.f95 -o quaternions
$ ./quaternions
Quaternions example:
a = ( 5.00, 6.00, 7.00, 8.00)
b = ( 1.00, 2.00, 3.00, 4.00)
c = a + b
c = ( 6.00, 8.00, 10.00, 12.00)
c = a - b
c = ( 4.00, 4.00, 4.00, 4.00)
c = a * b
c = ( -60.00, 20.00, -18.00, 32.00)
-
ja bych si furt myslel, ze na numericke pocitani ol'good fortran a jeste mpi na cluster.
Pro paralelní zpracování (HPC clustery) má pěkná rozšíření Fortran 2018.
a jak vies ze tie rozsirenia su pekne, ked si povedal ze vo fortrane neprogramujes :) btw. ja som asi iba raz v zivote experimentalne pouzil OpenMP
-
Tak s tymi Quaternionmi to samozrejme vo Fortrane ide.
::)
-
a jak vies ze tie rozsirenia su pekne, ked si povedal ze vo fortrane neprogramujes
To jsem nikdy neřekl, jen že nepoužívám GNU Fortran a nepotřebuju v něm OOP, to je docela rozdíl.
-
něco jako rustí std::io::Read nebo io.Reader (Go)
K tomuto jsem zapomněl dodat, že zrovna pro read/write Fortran plnohodnotné “traity” má.
-
Este som tie kvaterniony trochu zmenil, teraz nepouzivam overloading assignemt operatora = aby som naplnil kvaternion z pola
a = (/1., 2., 3., 4./)
ale vytvaram ho à la OOP takto:
a = Quaternion(1., 2., 3., 4.)
Takze modul mi sluzi ako class pre kvaternion, dodal som tam aj metodu print ktora sa pouzica tymto sposobom
a%print
quaternions_class.f95
module my_quaternions
type :: Quaternion
real :: x, y, z, t
contains
procedure :: print => print_quaternion
end type quaternion
interface operator(+)
module procedure add_quaternions
end interface
interface operator(-)
module procedure substract_quaternions
end interface
interface operator(*)
module procedure hamilton_product
end interface
contains
subroutine print_quaternion(this)
class(Quaternion), intent(in) :: this
write (*, 10) '(', this%x, ', ', this%y, ', ', this%z, ', ', this%t, ')'
write (*,*)
10 format(a, f8.2, a, f8.2, a, f8.2, a, f8.2, a)
end subroutine print_quaternion
function add_quaternions(a, b) result(c)
type(Quaternion), intent(in) :: a
type(Quaternion), intent(in) :: b
type(quaternion) :: c
c%x = a%x + b%x
c%y = a%y + b%y
c%z = a%z + b%z
c%t = a%t + b%t
end function add_quaternions
function substract_quaternions(a, b) result(c)
type(quaternion), intent(in) :: a, b
type(quaternion) :: c
c%x = a%x - b%x
c%y = a%y - b%y
c%z = a%z - b%z
c%t = a%t - b%t
end function substract_quaternions
function hamilton_product(a, b) result(c)
type(quaternion), intent(in) :: a, b
type(quaternion) :: c
c%x = a%x*b%x - a%y*b%y - a%z*b%z - a%t*b%t
c%y = a%x*b%y + a%y*b%x + a%z*b%t - a%t*b%z
c%z = a%x*b%z - a%y*b%t + a%z*b%x - a%t*b%y
c%t = a%x*b%t + a%y*b%z - a%z*b%y + a%t*b%x
end function hamilton_product
end module my_quaternions
program quaternions
use my_quaternions
type(Quaternion) :: a, b, c
b = Quaternion(1., 2., 3., 4.)
a = Quaternion(5., 6., 7., 8.)
write(*, '(a)', advance="no") 'a = '
call a%print()
write(*, '(a)', advance="no") 'b = '
call b%print()
write (*,'(a)') 'c = a + b'
c = a + b
write(*, '(a)', advance="no") 'c = '
call c%print
write (*,'(a)') 'c = a - b'
c = a - b
call c%print
write (*,'(a)') 'c = a * b'
c = a * b
call c%print
end program quaternions
Output:
$ gfortran quaternions_class.f95 -o quaternions_class
$ ./quaternions_class
a = ( 5.00, 6.00, 7.00, 8.00)
b = ( 1.00, 2.00, 3.00, 4.00)
c = a + b
c = ( 6.00, 8.00, 10.00, 12.00)
c = a - b
( 4.00, 4.00, 4.00, 4.00)
c = a * b
( -60.00, 20.00, -18.00, 32.00)
-
... viz co psal Ink. Moduly jsou jen jmenné prostory ...
Never nikomu, kym si to sam neoveris. Nie su to len name spaces - nainstaluj si gfortran a pozri si moj predosly priklad quaternions_class.f95. Modul tu robi taku istu pracu ako class a ma aj metodu print.
-
... viz co psal Ink. Moduly jsou jen jmenné prostory ...
Never nikomu, kym si to sam neoveris.
Dobrá rada, ale vzhledem k tomu, že znám Fortran i ostatní věci, o kterých Ink psal, můžu z fleku říct, že on má pravdu a ty se ukrutně pleteš.
Jo a v tom příkladu chybí právě ty “generic bindings” aka traity.
-
Tak nestíhám zdejší diskuzi a nechci se tedy klonit na žádnou stranu. Podle mne je OOP i ve Fortranu, pokud se používá jen v nějakých částech aplikace, akceptovatelné. Možná poslouží i na nějaký převod původně OOP designu z C++ do Fortranu. Ale moduly jak ukazuje mikrom jsou dobrá cesta. Tak kéž by aspoň lidi ve Fortranu psali jako mikrom :D. Za každého Fortranistu jsem rád. Jinak co se týká teorie Idris má většinou pravdu. Proč se s ním hádat ;)
-
moduly jsou dobrá cesta
To tady nikdo nerozporuje, a týká se to asi všech jazyků.
A ano, buďme rádi za každého fortranistu, naprostý souhlas :)
-
Podle mne je OOP i ve Fortranu, pokud se používá jen v nějakých částech aplikace, akceptovatelné. Možná poslouží i na nějaký převod původně OOP designu z C++ do Fortranu.
Taky souhlas (když se používá rozumně). Ono v době přidání OOP do Fortranu zrovna letěl styl Java, bylo do dávno před (typovými systémy) Rustu, Julie či Go.
BTW co se mi z nových návrhů hodně líbí jsou šablony: https://everythingfunctional.wordpress.com/2022/07/24/the-state-of-fortran-generics/
Trochu se tváří jako ty v C++, ale s těmi omezeními (restriction) to bude super, pokud to takto projde. Kdo má furt používat m4, že?
-
ja bych si furt myslel, ze na numericke pocitani ol'good fortran
Ono to tak většinou je. Ostatně, jak jednou napsal zdejší plodný autor p. Tišnovský, Fortran je v podstatě jen DSL.
-
... viz co psal Ink. Moduly jsou jen jmenné prostory ...
Never nikomu, kym si to sam neoveris.
Dobrá rada, ale vzhledem k tomu, že znám Fortran i ostatní věci, o kterých Ink psal, můžu z fleku říct, že on má pravdu a ty se ukrutně pleteš.
Zial neni to tak, dajme k tomu maly dokaz sporom ;)
Nech teda su moduly name spaces. Potom ale, ked mam 2 rozne moduly, ktore obsahuju premennu s rovnakym menom, viem jej pouzitie rozlisit na zaklade mena modulu, t.j. takto:
module MA
character(20) :: foo = 'foo from module A'
end module MA
module MB
character(20) :: foo = 'foo from module B'
end module MB
program namespaces
use MA
use MB
write(*,*) MA%foo
write(*,*) MB%foo
end program namespaces
Ked sa vsak pokusim skompilovat to dostanem chybu
$ gfortran namespaces.f95 -o namespaces
namespaces.f95:12:17:
write(*,*) MA%foo
1
Error: Symbol at (1) is not appropriate for an expression
namespaces.f95:13:17:
write(*,*) MB%foo
1
Error: Symbol at (1) is not appropriate for an expression
Takuto chybu dostanem aj ked namiesto % pouzijem . alebo => atd.
To znamena, ze na zaklade mena modulu sa neda rozlisit, z ktoreho modulu rovnomenna premenna je.
Z toho vyplyva, ze moduly nie su menne priestory a ty nemas pravdu 8)
Jinak co se týká teorie Idris má většinou pravdu. Proč se s ním hádat ;)
Ako som hore ukazal - je mi luto ale tentoraz pravdu nema.
Idris nam tu sice dava sebavedome a silne tvrdenia a po teoretickej stranke ma toho iste velmi vela precitane. Ale pripada mi to ako ked studuje v matematike definicie a vety bez praktickych cviceni. Moze sice ostatnych ohurovat ake je v tom eso, ale hlbsie pochopenie prichadza az pri rieseni praktickych uloh.
Moduly vo fortrane nie su namespaces. Fortran nema name spaces.
Namespaces si ale mozes v moduloch vytvorit pomocou derived data types a to takto:
module MA
type MA_T
character(20) :: foo = 'foo from module A'
end type
type(MA_T) :: A
end module MA
module MB
type MB_T
character(20) :: foo = 'foo from module B'
end type
type(MB_T) :: B
end module MB
program namespaces
use MA
use MB
write(*,*) A%foo
write(*,*) B%foo
end program namespaces
Output:
$ gfortran namespaces.f95 -o namespaces
$ ./namespaces
foo from module A
foo from module B
-
Podle mne je OOP i ve Fortranu, pokud se používá jen v nějakých částech aplikace, akceptovatelné. Možná poslouží i na nějaký převod původně OOP designu z C++ do Fortranu.
Taky souhlas (když se používá rozumně). Ono v době přidání OOP do Fortranu zrovna letěl styl Java, bylo do dávno před (typovými systémy) Rustu, Julie či Go.
BTW co se mi z nových návrhů hodně líbí jsou šablony: https://everythingfunctional.wordpress.com/2022/07/24/the-state-of-fortran-generics/
Trochu se tváří jako ty v C++, ale s těmi omezeními (restriction) to bude super, pokud to takto projde. Kdo má furt používat m4, že?
Typový systém Rustu vychází z Haskellu (1990) a ML (1973).
-
Typový systém Rustu vychází z Haskellu (1990) a ML (1973).
Akorát nemá HKT a už vůbec ne GADT.
-
Typový systém Rustu vychází z Haskellu (1990) a ML (1973).
Akorát nemá HKT a už vůbec ne GADT.
...zatím
-
Typový systém Rustu vychází z Haskellu (1990) a ML (1973).
Akorát nemá HKT a už vůbec ne GADT.
...zatím
To by bylo fajn. Doufám, že nebudeme čekat moc dlouho.