Re: Eu 4.2.0 Beta?

new topic     » goto parent     » topic index » view thread      » older message » newer message
ghaberek said...
SDPringle said...

The ability to set constants in routines rather than only variables.

Constants in routines, like this:

procedure foobar() 
    constant FOOBAR = 1234 
end procedure 

Or constant routines, like this:

constant function foobar() 
    atom some_value = 42 
    return some_value -- cannot be modified by the caller 
end function 

I can see both being useful, especially the latter for use with classes.

I meant the former. Euphoria being copy on write, I don't appreciate the benefit of the second interpretation you have. In something that looks like copy by value (but is copy on write), why should we care whether a caller modifies it?

ghaberek said...
SDPringle said...

delete should be something that not only calls the destructor but takes the passed variable out of scope at the point in the routine it is called.

...NOVALUE and that will cause an error and crash. The front end could hide the symbol when delete() is called but it'd be hiding the symbol from itself, so further assignments would also fail unless more scanning was done to look ahead for future assignments. A good middle ground might be to issue a warning about potential "use after delete" or something.

One could mark variables in the parser as deleted. Making people declare a new variable rather than recycling variables and if they can reuse the same name, it wouldn't bother me much. Such delete statements would then have to be restricted to be the same level as the declaration. (not with in a branch or something)....

ghaberek said...
SDPringle said...

statements like b += func(), where func() sets b should throw an error rather than overriding changes of the variable b as the language does now. I'd love someone to convince me why this is a good idea. It is not obvious without understanding the front-end code to some degree, but a lot of effort was put in to make this work consistently this way

I was unaware this behavior existing. I'm curious so I'll dig into it at some point so I can at least understand how it works today.

Remember in the forum threads a long long time ago... someone posted this problem where the program simulates throwing a ball over a wall. The program has to catch it. Some how the ball never gets caught. It gets lost. He couldn't figure out why, and neither could we.

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


Quick Links

User menu

Not signed in.

Misc Menu