What are OOP's Jargons and Complexities?
in [Perl]
|
Prev: swift MT940 files
Next: Is there neq for strings?
From: Thomas G. Marshall on 24 May 2005 11:55 John W. Kennedy coughed up: > alex goldman wrote: >> John W. Kennedy wrote: >> >> >>> Strong >>> typing has been a feature of mainstream programming languages since >>> the late 1950's. >> >> >> Is Fortran a strongly typed language? I don't think so. Strong >> typing has been invented in the 70's, if I'm not mistaken, when ML >> was invented, but strong typing has never been mainstream. > > I begin to believe that I have been reading naughty references, and > that I should rather have said "statically typed". > > I am not familiar with modern Fortran. Surely it at least has argument > prototyping by now? There are some fortran advocates that pop into here now and again. Frankly, I'm spooked by how far fortran seems to have come. There is even OO support now. OI. I preferred the old days of thinking that fortran sucked "just 'cause". :) -- Enough is enough. It is /not/ a requirement that someone must google relentlessly for an answer before posting in usenet. Newsgroups are for discussions. Discussions do /not/ necessitate prior research. If you are bothered by someone asking a question without taking time to look something up, simply do not respond.
From: Matthias Buelow on 24 May 2005 14:13 Andreas Rottmann wrote: > You get terminology totally wrong here. As already said, Lisp is > stronger typed than C, but C is statically typed, whereas Lisp is > dynamically typed. In Lisp (or Scheme), all variables have types: > > (define foo #(1 2 3)) > (vector? foo) => #t > (boolean? foo) => #t Hmm.. weird Scheme you're using here. Normally you have to quote the vector (see R5RS, 6.2.6) because it is not self-evaluating, and boolean? should not return true on vectors (6.3.1). I get (on scheme48): (define foo '#(1 2 3)) (vector? foo) => #t (boolean? foo) => #f mkb.
From: Wibble on 24 May 2005 21:00 Thats how common lisp specifies a vector. Andreas, your link indicates that lisp is a Weakly typed language not strong. Theres no compile time type semantics, at least in CommonLisp, MacLisp, ZetaLisp or FranzLisp. (setq foo #(1 2 3)) (setq foo 1) (setq foo "Whatever") Theres no type associated with foo, only with what the variable is currently referencing. From your link: When the types detected or declared are strictly enforced by the language's semantics, the language is strongly-typed. when the semantics of the language allows for inconsistencies between the compile-time type and the run-time type, the language is weakly-typed. Matthias Buelow wrote: > Andreas Rottmann wrote: > > >>You get terminology totally wrong here. As already said, Lisp is >>stronger typed than C, but C is statically typed, whereas Lisp is >>dynamically typed. In Lisp (or Scheme), all variables have types: >> >>(define foo #(1 2 3)) >>(vector? foo) => #t >>(boolean? foo) => #t > > > Hmm.. weird Scheme you're using here. > Normally you have to quote the vector (see R5RS, 6.2.6) because it is > not self-evaluating, and boolean? should not return true on vectors (6.3.1). > > I get (on scheme48): > > (define foo '#(1 2 3)) > (vector? foo) => #t > (boolean? foo) => #f > > > mkb.
From: Paul Rubin on 24 May 2005 21:20 Wibble <Wibble(a)Mailinator.com> writes: > Andreas, your link indicates that lisp is a Weakly typed language not > strong. Theres no compile time type semantics, at least in CommonLisp, > MacLisp, ZetaLisp or FranzLisp. There are runtime semantics that enforce types. > From your link: > When the types detected or declared are strictly enforced by the > language's semantics, the language is strongly-typed. > when the semantics of the language allows for inconsistencies between > the compile-time type and the run-time type, the language is > weakly-typed. Yes, the compile-time type of 3 is integer, and the runtime type of 3 is also integer. There is no inconsistency. Compare that with C, which lets you cast 3 to a pointer.
From: beliavsky on 24 May 2005 22:34
Thomas G. Marshall wrote: > > I am not familiar with modern Fortran. Surely it at least has argument > > prototyping by now? Since the 1990 standard, if Fortran subroutines and functions are placed in MODULEs, or if INTERFACEs are provided, the compiler checks that procedures are called with the right types (int or float, scalar or array, etc.) of arguments. > There are some fortran advocates that pop into here now and again. Frankly, > I'm spooked by how far fortran seems to have come. There is even OO support > now. OI. Some Fortranners think the language has gotten too big and complicated, sounding a bit like C programmers complaining about C++ (I don't mean that pejoratively). |