Re: Namespaces
Ralf wrote:
>> Wait for the next release. If it's still
>> broken, complain again.
>
> Yes, but I just don't want variable names to get
> any longer than they already are. I don't want
> the filename as part of the variable name.
If you want, you can import the module into the current namespace with:
import "foo.py"
I'll also probably add the Python-styled import:
from "foo.py" import x, y, z
that should take care of the issue.
I have no idea how Robert might want to approach this in Euphoria.
> Secondly, you should only be able to import
> global variables. Local variables are "hands-off".
> Otherwise there is no way to lock an include, and
> the type of errors and issues you have to deal with.
> No way.
That's true, you can't lock an include. I'm taking the Python route here,
where enforcement is more a matter of policy.
Put it this way: when was the last time you got a compiler error warning you
were changing the value of a constant?
> find each ' ' in "Hello World, how many spaces ?" as pos do
> printf (1, "Found a space at %d \n", {pos})
> end find
There's a chance that a LISP-style map/apply sort of routine will be added
at some point. I've always wanted one of those for Euphoria, although I
suppose you can emulate them with routine_id. It would be a lot easier if
routine_id were scoped differently; then you could write something like:
function apply( sequence s, sequence routine )
integer id
id = routine_id(routine)
if id = -1 then
printf( 1, "can't apply routine, %s not defined", {routine} )
abort 0
else
for i = 1 to length(s) do
s[i] = call_func( id, {s[i]} )
end for
end if
return s
end function
Here's an entirely worthless example:
-- convert red to green
function red_to_green( integer i )
if i = red then
return green
else
return i
end if
end function
s = apply( s, "red_to_green" )
> { eof_status, value } = get (0)
Just write:
eof_status, value = get(0)
After looking at Python, it became obvious that there was no reason to use
braces in the syntax. It'll be nice if Robert decides to add this to
Euphoria; I really like this notation.
> Yes, but what if there is NO result?
You don't like to read the documentation, do you?
Actually, there was a longer discussion about this in the original
documentation, but didn't make it to the current docs.
You don't need to return a result; Py will automatically return a zero value
for you. If I had access to the Euphoria innards, I'd have it return a
'Null' or something.
The catch is that you *always* have to use a return value with the 'return'
statement. If you don't intend to use it, just write:
return 0
The reason for *having* to return a result have to do with the parser not
having more than 1 token look ahead. Jiri suggested using (), like so:
return ( expr ) -- return expr
return -- no explicit return value
but that would require, on average, more work for the coder, and more
chances for typos. So for now, I'm opting for a required value.
-- David Cuny
|
Not Categorized, Please Help
|
|