Re: Win32LIb/Llama Status
>] Anyway, Euphoria decides that the second "set" is a name conflict, and the
>] next "set" that follows... each is renamed some symbol like "Dg" or "Lw",
>] despite the -clear_routines option being selected.
>]
>] Naturally, routine_id can't find the renamed symbol, and Llama returns error
>] after error about methods not being defined.
>]
<snip>
>I think if this were to be fixed, BIND and SHROUD would have to become
>2-pass compilers, which is something Rob wanted to avoid.
>
>I'm just trying to think it through as I type...
>
>Yup. Solved it, and it *doesn't* have to be 2-pass.
>Routine_Ids should be set at compile time. They can't possibly change, so
>I think this is a vialable option.
>
>e.g.
>
>function foo()
> return time()
>end function
>
>bar = routine_id("foo")
>
>Compiles to
>
>function_token foo_tag ( ) return_token time_token ( ) end_token
>function_token bar_tag = constant_from_id_table_for_foo
>
>..or whatever. Notice it removes the need for a token for routine_id,
>since it never gets used.
>
>IMHO, it's a perfect argument for including and appending to an internal
>routine_id() table for the interpreter.
Hmmm... might work. But we'd still need the routine_id token as well,
otherwise you couldn't get one on the fly:
sequence RoutineName
puts (1, "Enter procedure name to execute: ")
gets (RoutineName)
exec_procedure (routine_id (RoutineName), {})
RoutineName = GetInternalRoutine () -- determines another routine to use
exec_procedure (routine_id ("BuiltIn" & RoutineName), {})
But then, were Llama ever to construct the name of the routine, rather
than relying on a literal, we'd still run into the same problem... yuck.
>We could then also do things like 'bar = routine_id("time")', without
>having to define a wrapper function like 'foo()'.
Well, I'm really not too sure why we can't do this already. Then again,
I didn't write Euphoria... 
Rod Jackson
|
Not Categorized, Please Help
|
|
