Hi Brian, I sure enjoy your thoughts on the subject. I can certainly do without typed functions, but as long as they're optional ... Why not separate function constructors which support return type enforcement from functions that don't? Let's say we wish to enforce types or automatically convert types. This example auto-converts. Example usage: >> f: rt-func [a /local return-type [string!] ] [return a] Note that the return-type is entered in the /local part of the function's specification block (cheap trick, simplifies my implementation of rt-func somewhat). >> f 1 == "1" >> f [EMAIL PROTECTED] == "[EMAIL PROTECTED]" >> f http://www.rebol.com == "http://www.rebol.com" >> f 123.128.000 == "123.128.0" >> f [a b d] == "abd" >> f: rt-func [a /local return-type [block!] ] [return a] >> f 1 == [1] >> f [EMAIL PROTECTED] == [[EMAIL PROTECTED]] >> f http://www.rebol.com == [http://www.rebol.com] >> f [a b d] == [a b d] Later we go into production and want to optimize for speed (no auto-conversion). We set rt-func to func: >> rt-func: :func and now our functions behave normal: >> f: rt-func [a /local return-type [string!] ] [return a] >> f 1 == 1 >> f [EMAIL PROTECTED] == [EMAIL PROTECTED] >> f http://www.rebol.com == http://www.rebol.com >> f 123.128.000 == 123.128.0 The function rt-func could look something like this DISCLAIMERS Warning this is not production quality code. Just a rough draft, to get an idea. Does not support results of type object!: >> f make object! [a: none] == "?object?" "Things that can't be converted are not handled intelligently!" (TM) Probably there are other exceptions. A more careful approach would be to first check whether the function prototype contains the return-type word ... rt-func: func [spec [block!] body [block!] ] [ insert body compose/deep [ return: func [result /local return-type] [ return-type: (spec/return-type) system/words/return to return-type result ] ] remove/part find spec 'return-type 2 append spec [return] return func spec body ] At 04:56 PM 4/4/00 -0500, you wrote: >Hi Elan, > >You wrote: >> I don't see any harm in having a type specifier as part of >> the function declaration, which enforces a return type ... >> as long as it's *optional* ;-). > >How would this be enforced in an interpreted language that >creates its functions at runtime? > >Testing for return type at function creation time would need >a type-inference engine to determine the type. Type inference >is too slow to do at runtime. Type inference could not possibly be complete, since any function can be called via REBOL console. How do you infer the type of user input? > >Testing for return type at function execution time would add >an type-checking exception after the end of the function block. The only possible solution. >The function code wouldn't be able to handle such an exception, >so it would have to ensure that the error couldn't occur using >internal error-checking code, which would mean that the built-in >return type-checking code would just be overhead. Sure would. > >> Something like: >> >> func [ a [any-type!] b [integer!] /local ... /return [any-type!]] [ >> ] >> >> Perhaps with auto-conversion? > >I noticed that you put the return type you listed was in a block. >Blocks are used for the other types so that multiple types could >be specified. If multiple types are specified, which type do you >auto-convert to? First one by default. >What about conversions that aren't so automatic? > Too bad. >Functions in REBOL are often polymorphic, returning types that >depend on the types or values of their arguments. Which is the reason I don't quite see why return type checking is so important. >Any conversion >or type checking in such an environment is better done manually. >It's usually faster too, because you can remove tests where they >aren't needed. See above. > >A type inference engine would be a great development-time tool >to check your code before release, though. It would be a good >thing to have for documentation too. Perhaps, when I have a little more time. > >Wanna write one? ;-) >Brian > > > ;- Elan >> [: - )]
