1. Differences between type_checks(was RE: haha very funny)
- Posted by bensler at mail.com Oct 22, 2001
- 367 views
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)
- Posted by Robert Craig <rds at RapidEuphoria.com> Oct 22, 2001
- 363 views
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)
- Posted by euphoria at carlw.legend.uk.com Oct 23, 2001
- 341 views
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