From: Conrad Taylor
Subject: Is LISP and/or Scheme considered to be untyped...???
Date:
Message-ID: <CCBz0n.1z9@sparc0a.cs.uiuc.edu>
Well, I was wondering, are LISP and/or Scheme considered
to be untyped languages? I have worked with both Scheme and LISP
and know that they don't explicitly declare the types of an object/
variable. However, I think this might be an option with LISP.
Furthermore, I have read that both Scheme is dynamically typed and
LISP is both dynamically and statically typed. So, with the above
facts would these two languages be considered to be untyped? Also,
if you have any references which verifies or denies the above, please
e-mail me the info for the reference with your reply.
Thanks in advance,
-Con
From: Brian Harvey
Subject: Re: Is LISP and/or Scheme considered to be untyped...???
Date:
Message-ID: <25gm7g$k27@agate.berkeley.edu>
·······@sparc7.cs.uiuc.edu (Conrad Taylor) writes:
> Well, I was wondering, are LISP and/or Scheme considered
>to be untyped languages?
I thought I'd try answering this on the newsgroup so I can find out if
I have the same answer as everybody else.
The phrase "untyped language" is a loose shorthand that could be understood
in two ways, hence the confusion. It's not languages that have types, but
rather data, and variables.
1. A language with untyped data would be one in which any datum can be used
in any context. This doesn't make much sense -- what's the CAR of a number?
What's the SIN of a pair? However, there are languages that come close, in
that there is one principal type, and certain subsets work in certain contexts.
For example, in SNOBOL, the only official type is "string," but you can do
arithmetic on a string if it happens to contain only digits. AWK also has
that property, although AWK also has [unordered] arrays of strings.
2. A language with untyped variables is one in which the programmer does
not have to restrict a variable in advance to containing only values of a
certain type. This is what people usually mean when they say "untyped
language." As you say, Scheme is entirely untyped in this sense, while
Common Lisp [I hate it when people say "Lisp" and mean only Common Lisp]
has optional type declarations for variables.
3. If variables are untyped, then there has to be some way to know what the
type of any particular value is. Generally this means that every datum must
carry around a type number that can be tested; this is how the type predicates
like NUMBER? or PAIR? work, since on most computers there's no inherent way
to distinguish between an integer and a pointer.
4. The terminology for this topic is confused. SICP uses "manifest type" to
describe the state of affairs in which every datum has a type tag attached.
R4RS calls this "latent type" and uses the phrase "manifest type" to describe
the situation in which the type is associated with the variable rather than
with the value. R4RS goes on to suggest synonyms in the literature:
latent = weak = dynamic ( = SICP "manifest" = "untyped" )
manifest = strong = static
I guess it depends whether you're focusing on the datum or on the variable,
which you want to call "manifest."
Hope this helps.
From: Bill Vrotney
Subject: Re: Is LISP and/or Scheme considered to be untyped...???
Date:
Message-ID: <1993Aug25.234121.11391@ads.com>
In article <··········@agate.berkeley.edu> ··@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>
> 4. The terminology for this topic is confused. SICP uses "manifest type" to
> describe the state of affairs in which every datum has a type tag attached.
> R4RS calls this "latent type" and uses the phrase "manifest type" to describe
> the situation in which the type is associated with the variable rather than
> with the value. R4RS goes on to suggest synonyms in the literature:
> latent = weak = dynamic ( = SICP "manifest" = "untyped" )
> manifest = strong = static
> I guess it depends whether you're focusing on the datum or on the variable,
> which you want to call "manifest."
>
To change the subject slightly. As I do more and more AI programming in Lisp
I find myself doing more and more explicit type checking. It seems to be a
powerful device. When I consider replacing that type checking code with its
analogue (not implementing a type tag) in a statically typed language like
C++ it seems like it will be more INEFFICIENT, contrary to the one of the
selling points of statically typed languages. Of course if I implement a
dynamic type tag in a statically typed language that corresponds to roughly
the same thing, then its efficiently seems to become a separate argument and
other issues come into play.
My question is, has anyone researched the thesis that "dynamically typed
languages start becoming MORE efficient than statically typed languages for
complex programs that use explicit type checking"? Or am I overstating the
obvious?
--
Bill Vrotney
BAH/Advanced Decision Systems
········@ADS.COM (Bill Vrotney) writes:
[...]
>My question is, has anyone researched the thesis that "dynamically typed
>languages start becoming MORE efficient than statically typed languages for
>complex programs that use explicit type checking"? Or am I overstating the
>obvious?
What do you mean by 'efficient'?
The runtime of the compiled program or the time to write it ?
As stated in some postings a few days ago, declaring types makes Lisp
code as efficient as C code. There is no extra overhead to perform the
type checking, the type checking is not needed when Lisp types are
declared. I think, a good lisp compiler would use the knowledge of the
objects type a compilation time to write some special code for
frequently used typed (ints, real).
Or did I get you wrong ?
Since I use Lisp to bring some more efficient modules to my programs
(caching of data and others that would be to complicated for me in
C[++]), the thesis above applies for my programs (although caching has
noting to do with type checking issues) for runtime, not to speak of
development time.
[excuse me for some bad english]
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de>,Voice+4940-5221829,Fax.-5228536
------ C is a good language - for implementing programming systems -------
>>>>> "MC" == Martin Cracauer writes:
MC> ········@ADS.COM (Bill Vrotney) writes:
MC> [...]
>My question is, has anyone researched the thesis that "dynamically typed
>languages start becoming MORE efficient than statically typed languages for
>complex programs that use explicit type checking"? Or am I overstating the
>obvious?
MC> As stated in some postings a few days ago, declaring types makes Lisp
MC> code as efficient as C code. There is no extra overhead to perform
MC> ....
MC> Or did I get you wrong ?
I think the original poster's point was that in large programs, you
often cannot determine the types of objects at compile time. To sort
things out at runtime in a language like C, you have to include
explicit type tags and do your own dispatch. The claim/question is
whether Lisp's built-in dynamic typing might not be more efficient in
such cases.
As an example, we are starting to port a large NLP program from
Lisp/Clos to C++. The system is built on top of a blackboard as the
basic control structure. Objects (or "notes") of a wide variety of
types get posted on the blackboard. For example, we look up each input
word in the lexicon: if lookup succeeds, we post a "Word-Note"
containing the dictionary entry for the word - but if we don't find
the word in the lexicon, we post a "Failure-Note" indicating that we
have to query the user to correct the spelling or guess at what the
word is, etc. So we can't tell at _compile_ time whether we will have
objects of type Failure-Note on the blackboard or not.
In the Lisp/Clos version, we just make Word-Note and Failure-Note
sub-types of the general class Note, and write specialized methods for
them. I'm too new to the port to know how far virtual functions in C++
will take us, but it's likely that we will have to explicitly record
the type on each Note and do our own dispatching (for starters, we
often dispatch on more than one argument.) As an inveterate Lisp
programmer, I find this an an even bigger handicap than the lack of a
GC.
We've just gotten started on the port, but I doubt that this explict
dispatch would end up being slower at runtime than the Lisp version.
It'll just be a pain to write and maintain. But we all knew that about
C++ already, right?
- Jim
From: Fernando Mato Mira
Subject: Re: Is LISP and/or Scheme considered to be untyped...???
Date:
Message-ID: <25lkek$lud@disuns2.epfl.ch>
In article <·····················@neutron.mcc.com>, ·······@neutron.mcc.com (Jim Barnett) writes:
> As an example, we are starting to port a large NLP program from
> Lisp/Clos to C++.
Why? Haven't we reached the point where a Lisp/Clos program can be faster than
a C++ one?
--
Fernando D. Mato Mira
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248
CH-1015 Lausanne FAX : +41 (21) 693 - 5328
Switzerland E-mail : ········@di.epfl.ch
"Check any C++ program. What do you see? Inefficient type checking,
(casted) dynamic dispatching, hacked garbage collectors,
string-based (yikes!) keyword arguments...
Have you driven a LISP, lately? "
>>>>> "FMM" == Fernando Mato Mira writes:
FMM> In article <·····················@neutron.mcc.com>, ·······@neutron.mcc.com (Jim Barnett) writes:
> As an example, we are starting to port a large NLP program from
> Lisp/Clos to C++.
FMM> Why? Haven't we reached the point where a Lisp/Clos program can be faster than
FMM> a C++ one?
Yes. Unfortunately a long time ago we reached the point where
technical decisions were made by marketing and management types who
didn't know squatone about technology. C++ sells, Lisp doesn't, and
we're interested in surviving...
The closest thing to a rational technical reason in our decision is
Lisp's need for (relatively) expensive runtime support. We can't just
send a Sparc executable to a sponsor - he needs to buy a license for
whatever brand of commercial Lisp we're using. (Businesses don't want
to hear about free Lisps - they want to deal with a Real Company that
has an 800-number. The Perl newsgroup is full of complaints from
people whose bosses won't let them use Perl because it's not a Real
Product - and Perl is one of the best-debugged, best-supported
languages around.)
In article <·····················@neutron.mcc.com> ·······@neutron.mcc.com (Jim Barnett) writes:
FMM>(Jim Barnett) writes:
> As an example, we are starting to port a large NLP program from
> Lisp/Clos to C++.
FMM> Why? Haven't we reached the point where a Lisp/Clos program can be faster than
FMM> a C++ one?
Yes. Unfortunately a long time ago we reached the point where
technical decisions were made by marketing and management types who
didn't know squatone about technology. C++ sells, Lisp doesn't, and
we're interested in surviving...
The closest thing to a rational technical reason in our decision is
Lisp's need for (relatively) expensive runtime support. We can't just
send a Sparc executable to a sponsor - he needs to buy a license for
whatever brand of commercial Lisp we're using.
This is not true of all Lisps. Ilog Talk is runtime-free for the
basic libraries and interpreter. The development environment requires
a license for distribution. Mail to ····@ilog.com for more information.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
In article <··········@agate.berkeley.edu>,
Brian Harvey <··@anarres.CS.Berkeley.EDU> wrote:
> latent = weak = dynamic ( = SICP "manifest" = "untyped" )
> manifest = strong = static
The other distinction you used to often see was:
explicitly typed vs. implicitly typed
( i.e. explicit by declaration or by reserved namespace )
but type inference schemes have muddied that distinction somewhat.
- Steve Majewski
From: ··@anarres.CS.Berkeley.EDU (Brian Harvey)
Date: 25 Aug 1993 21:40:00 GMT
1. A language with untyped data would be one in which any datum
can be used in any context. This doesn't make much sense -- what's
the CAR of a number? What's the SIN of a pair? However, there are
languages that come close, in that there is one principal type, and
certain subsets work in certain contexts. For example, in SNOBOL,
the only official type is "string," but you can do arithmetic on a
string if it happens to contain only digits.
These remarks apply to SNOBOL3, but not to the much more widely known
SNOBOL4. SNOBOL4 has a rich set of data types, including records,
arrays, tables, patterns, and unevaluated expressions.
--
Jonathan Rees ···@cs.cornell.edu
member, Cambridge Entomological Club / member, League for Programming Freedom
In article <··········@agate.berkeley.edu> ··@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>3. If variables are untyped, then there has to be some way to know what the
>type of any particular value is. Generally this means that every datum must
>carry around a type number that can be tested; this is how the type predicates
>like NUMBER? or PAIR? work, since on most computers there's no inherent way
>to distinguish between an integer and a pointer.
I've been somewhat confused about some of the discussion recently
(in comp.lang.dylan, I think) about what a dynamically typed
language is. But I think I've almost got it now.
Is the idea that in a language like C, data doesn't carry around
a type tag? And the compiler maintains a table of what memory
addresses are being treated as what types. Then the compiler
generates an error when you try to call a function on the wrong
kind of type--but only because the compiler checked its table.
And at run-time, you have this and that function being called on
data at this and that address, but the functions don't check to
see what type it is they're being called on--the functions have
no way of doing this. In theory, if the compiler (or the
programmer?) screws up, sin() could be called on an address which
is supposed to be the start of a string, and sin() will happily
eat as many bytes as it's supposed to, thinking that this string
data represents a float or whatever it is that sin() thinks it's
reading. (I suppose this means that C has to have different
compiled versions of sin() for different number types, or else
the compiler has to insert coercion functions around the compiled
sin() or something. (Maybe I should have picked a non-numerical
function as my example, to make it simpler.))
And in Lisps, by contrast, it's at least the default that every
datum carries a type tag and functions usually check that type
tag if it matters (e.g. I can imagine that in many
implementations, CONS wouldn't care about the types of its
arguments, so CONS wouldn't have to check types).
Is all of this mostly correct? I think I understood the Lisp
part, but I've been confused about what it is that some other
languages do.
Thanks.
Marshall Abrams
····@midway.uchicago.edu
I've always considered the term ``untyped,'' at least when applied to Lisp, to
be a misnomer. A better term is ``latent typing'' (I don't remember who to
credit with this name). Programming languages can be divided into three
catagories:
Untyped Languages
Assembly language and B, the predecessor to C, come to mind. Values are just a
collection of bits. A program can apply any operation to any bit pattern and no
one will complain (except the user of the program).
Latently-Typed Languages
Lisp. Values carry their types around with them. A program can apply any
operation to any value and the compiler will not complain, but the run-time
system (should) will.
Statically-Typed Languages
C (most of the time), Pascal, Ada, ML, .... The compiler checks to ensure that
each operator is applied to values of the correct type. Note that static typing
does not require type declarations, as demonstrated by ML.
/Jim
James Larus
Computer Sciences Department
University of Wisconsin--Madison
From: Vincent Manis
Subject: Re: Is LISP and/or Scheme considered to be untyped...???
Date:
Message-ID: <25m9vvINNcc8@cascade.cs.ubc.ca>
In article <······················@cs.wisc.edu> ·····@cs.wisc.edu writes:
>I've always considered the term ``untyped,'' at least when applied to Lisp, to
>be a misnomer. A better term is ``latent typing'' (I don't remember who to
>credit with this name). Programming languages can be divided into three
>catagories: [Untyped, Latent, and Statically-Typed]
This categorization was, to my knowledge, first defined by Christopher
Strachey in a paper sometime in the 1960's. It works pretty well.
I would add an orthogonal categorization:
* Languages with a fixed set of types, e.g., R4RS Scheme, Fortran-77.
* Languages with an infinite set of types which can be derived from a
set of base types according to a set of rules, e.g., Pascal, C, C++.
* Languages in which types are essentially first-class citizens, e.g.,
Oaklisp, Xerox Scheme (I think).
Am I correct in believing that R5RS will provide some mechanism for
user-defined types?
--
\ Vincent Manis <·····@cs.ubc.ca> "There is no law that vulgarity and
\ Computer Science, Langara College literary excellence cannot coexist."
/\ 100 W. 49th Ave, Vancouver, BC, Canada (604) 324-5205 -- A. Trevor Hodge
/ \ Co-author of ``The Schematics of Computation'', Prentice-Hall, Jan 1994
From: Isaac Rabinovitch
Subject: Re: Is LISP and/or Scheme considered to be untyped...???
Date:
Message-ID: <ergoCCDo4s.2wu@netcom.com>
··@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>·······@sparc7.cs.uiuc.edu (Conrad Taylor) writes:
>> Well, I was wondering, are LISP and/or Scheme considered
>>to be untyped languages?
>I thought I'd try answering this on the newsgroup so I can find out if
>I have the same answer as everybody else.
>The phrase "untyped language" is a loose shorthand that could be understood
>in two ways, hence the confusion. It's not languages that have types, but
>rather data, and variables.
>1. A language with untyped data would be one in which any datum can be used
>in any context. This doesn't make much sense -- what's the CAR of a number?
>What's the SIN of a pair?
I think you're making an artificial distinction here. I think a less
LISPian example makes this clear: in any useful language 1/"Brian" is
an error, but so is 1/0. One might well ask what's wrong with 1/0?
The denominator's the right type, isn't it? Perhaps you could say
that a untyped language would see both 1/0 and 1/"Brian" as domain
errors, whereas a typed language would see 1/"Brian" as a type error.
>2. A language with untyped variables is one in which the programmer does
>not have to restrict a variable in advance to containing only values of a
>certain type. This is what people usually mean when they say "untyped
>language." As you say, Scheme is entirely untyped in this sense, while
>Common Lisp [I hate it when people say "Lisp" and mean only Common Lisp]
>has optional type declarations for variables.
Whoa! What do you mean by "variable"? In Scheme, a variable is just
a name for an object -- *any* object, from "4" to "(lamda
philosopherstone ...)". The only identifiers in Scheme that aren't
"variables" are primitives. This is quite different from the way most
languages use the term.
Since Scheme is such a plastic language, I wonder if it has any place
in a discussion of "kinds of language".
>4. The terminology for this topic is confused. SICP uses "manifest type" to
>describe the state of affairs in which every datum has a type tag attached.
>R4RS calls this "latent type" and uses the phrase "manifest type" to describe
>the situation in which the type is associated with the variable rather than
>with the value. R4RS goes on to suggest synonyms in the literature:
> latent = weak = dynamic ( = SICP "manifest" = "untyped" )
> manifest = strong = static
>I guess it depends whether you're focusing on the datum or on the variable,
>which you want to call "manifest."
I think you're worrying too much about finding objective definitions
for words. When I'm trying to follow a discussion like this, I just
try to figure out how the speaker is using a term, and never mind if
his definition is 180 degrees away from my definition.
>Hope this helps.
--
····@netcom.com Isaac Rabinovitch
{apple,amdahl,claris}!netcom!ergo Santa Cruz, CA
"Can you prove it didn't happen?"
-- Criswell, epilogue to *Plan 9 from Outer Space*
I'm looking for a tool which would allow us to produce
a graph tree of our class hierarchy. I am familiar
with Allegro Composer and find that it is not suitable
because:
a) I can't print the tree out - the only print capability
available is to an emacs buffer and that is a textual
translation of the tree and not the graph itself, and
b) I cannot specify a depth - because the hierarchy is
both very deep and broad the output should be "pruned"
to make it more human-readable. One mechanism that I
identified that might help in this effort is one which
would allow me to select a depth somewhere between 1 and
leaf-node based on some personal knowledge that I have of
the class organizations or sub-trees.
Does anyone know of something else which might give me
what I'm looking for?
From: Brian Harvey
Subject: Re: Is LISP and/or Scheme considered to be untyped...???
Date:
Message-ID: <26fsbj$sig@agate.berkeley.edu>
····@netcom.com (Isaac Rabinovitch) writes:
>Whoa! What do you mean by "variable"? In Scheme, a variable is just
>a name for an object -- *any* object, from "4" to "(lamda
>philosopherstone ...)". The only identifiers in Scheme that aren't
>"variables" are primitives. This is quite different from the way most
>languages use the term.
I think you mean, the only identifiers in Scheme that aren't variables
are keywords -- the names of special forms. The names of primitives
are variables and can be rebound. For example, that's what you're doing
if you trace calls to a primitive (by wrapping a tracing procedure around
the actual primitive).
But, how is this different from the meaning of "variable" in any other
language? In any language, a variable is a name for an object. It's
just that in most languages the notion of "object" is impoverished (not
including procedures, for example).