Re: Namespaces

new topic     » goto parent     » topic index » view thread      » older message » newer message

Ralf wrote:

>> Wait for the next release. If it's still
>> broken, complain again. smile
>
> 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? blink

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu