1. Differences between type_checks(was RE: haha very funny)
- Posted by bensler at mail.com
Oct 22, 2001
Just curious,
Would there be any difference in speed between type checking an
integer and an atom?
From what I know, it's faster to type check an integer, but I would
THINK it would be faster to type check an atom since there are less
restictions for it.
How about type checking an object? I know it's redundant, but you can
do it. Does object() actually do any tests, or does it just return TRUE
every time? Or does object() actually type check a variable to verify
that it is CAST as an object?
Chris
Derek Parnell wrote:
> The documentation states that the dir() function can return either an
> atom or a sequence. This is consistent with other library calls too.
>
> >From the docs...
>
> Syntax: include file.e
> x = dir(st)
>
> and from the Part II - Library Routines Introduction...
>
> To indicate what kind of object may be passed in and returned, the
> following prefixes are used:
>
>
> x - a general object (atom or sequence)
> s - a sequence
> a - an atom
> i - an integer
> fn - an integer used as a file number
> st - a string sequence, or single-character atom
>
> Anyhow, this is how I use the dir() function...
>
> object d
> d = dir(FileSpec)
> if atom(d) then
> -- 'FileSpec' doesn't exist.
> else
> for i = 1 to length(d) do
> -- Process the files and directories...
> end for
> end if
>
> ---------
> Derek.
>
>
> euman at bellsouth.net wrote:
> > sequence dirs
> > dirs = dir(FileSpec)
> > for i = 1 to length(dirs) do
> >
> > dirs will actually contain file or directory info if there are any files
> >
> > or directories
> >
> > This from the Euphoria docs:
> >
> > d = dir(current_dir()) -- this says right up front dir( ) returns a
> > sequence doesnt it!
> >
> > -- d might have:
> > {
> > {".", "d", 0 1994, 1, 18, 9, 30, 02},
> > {"..", "d", 0 1994, 1, 18, 9, 20, 14},
> > {"fred", "ra", 2350, 1994, 1, 22, 17, 22, 40},
> > {"sub", "d" , 0, 1993, 9, 20, 8, 50, 12}
> > }
> >
> > OK, very well then, but when it doesnt contain info the return value is
> > -1 which
> > gives us a type_check error...
> >
> > OK then, we name dirs as an object and because we look for a length to
> > dirs
> > next we get this error message > length of an atom not defined.....huh
> >
> > this from the Euphoria Docs
> > If there is no file or directory with this name then -1 is returned
> >
> > OK, if we keep the dir defined as an object and run a test to make sure
> > dirs is not -1 like
> > this:
> >
> > if dir(FileSpec) != -1 then we get true/false condition must be an ATOM
> >
> > and damn I could list several other error messages and code but you all
> > get the point now.
> >
> > We are so restricted it's not funny...
> > I'll go to bed now.....later yall.
> >
> > Euman
> > euman at bellsouth.net
> >
> >
2. Re: Differences between type_checks(was RE: haha very funny)
Chris Bensler writes:
> Would there be any difference in speed between
> type checking an integer and an atom?
No. In both cases it just takes a single machine-level
comparison between two 32-bit integers.
e.g. in C:
if (a > b) ... it's an atom
or ...
if (a > c) ... it's an integer
In many instances, the interpreter, and especially the
translator, will know at compile-time that something
must be an integer, or must be an atom, and a
run-time test will not be performed.
> How about type checking an object? I know it's redundant,
> but you can do it. Does object() actually do any tests,
> or does it just return TRUE every time?
It just returns TRUE every time.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Differences between type_checks(was RE: haha very funny)
Robert Craig wrote:
> Chris Bensler writes:
>
> > How about type checking an object? I know it's redundant,
> > but you can do it. Does object() actually do any tests,
> > or does it just return TRUE every time?
>
> It just returns TRUE every time.
It's first thing in the morning here, so maybe I'm not thinking too clearly,
but maybe we could have object() return FALSE if the parameter (which would
have to be a variable for this to work) is undefined? e.g.:
---
integer s
? object(s) -- prints 0
s = 27
? object(s) -- prints 1
---
Or would that break too much existing code?
Come to think of it, what *does* object() do if it's parameter is undefined?
Does it complain before returning TRUE, or does it return TRUE and carry on
regardless?
Carl
