OpenEuphoria

1. find options

• Posted by SDPringle Mar 15, 2009
• 996 views

It would be useful to be able to pass a compare function to find and match. For when the key is not residing at the top of the structure.

Shawn

3. Re: find options

• Posted by SDPringle Mar 15, 2009
• 944 views

What is meant by 'automatic cleaning up' of user defined types?

Shawn

5. Re: find options

• Posted by jeremy (admin) Mar 15, 2009
• 964 views

Let's say you have wrapped PCRE. When you call pcre:new("[A-Z]+") memory is allocated and returned into euphoria as an atom. Take this example:

include pcre.e as r 
 
procedure is_proper_name(sequence s) 
    r:regex upperRx = r:new("[A-Z][a-z]+ [A-Z][a-z]+") 
    return r:match(upperRx, s) 
end procedure 

So, upperRx was allocated memory. I am unsure of how much each regex structure takes in PCRE, but it could be of a sizable amount. In Euphoria, we have garbage collection and we do not have to free memory as in C, that's one reason we program in Euphoria and not C. However, in the above example, we have leaked memory. the contents of upperRx can never be accessed again, nor is it free'd. The current way of dealing with the above code is this:

include pcre.e as r 
 
procedure is_proper_name(sequence s) 
    r:regex upperRx = r:new("[A-Z][a-z]+ [A-Z][a-z]+") 
    integer result = r:match(upperRx, s) 
    r:free(upperRx) 
    return result 
end procedure 

Now, the code is not so bad, but we have introduced having to deal with memory management in Euphoria, which is not nice. Now, we currently have user defined types that we can have. The addition we are speaking of will include a type cleanup method. This is all in design right now, but take this for example:

public type regex(object r) 
    -- validate r 
end type 
 
public type_cleanup regex(object r) 
    if r <> 0 then 
        pcre_free(r) 
    end if 
end type_cleanup 

Now, the above syntax I have no idea about. We have not discussed it yet, really. But, you get the idea. Now, go back up to the very first example. In this case, upperRx was assigned to a type of regex. When upperRx goes out of scope, Euphoria will now know to call the type_cleanup function associated with the regex user defined type.

This can be used in a few places in the standard library already. For instance, regular expressions and maps. Both of those currently require you to either call free or call delete which is pretty anti-Euphoria.

Jeremy

7. Re: destructor

• Posted by SDPringle Mar 15, 2009
• 966 views

A destructor system shouldn't need a bless() routine unless you want the interpreter to remember what a value is. In a static system. We need a way to connect the destructor to the type. Add a builtin: procedure register_destructor( integer tid, integer rid )

You can use a routine id of a type. The type gets attached. The parser could put the destructor routines in where variables go out of scope.

So, what will it be? Virtual methods or static ones?

Shawn Pringle

9. Re: destructor

• Posted by DerekParnell (admin) Mar 15, 2009
• 959 views

Because getting v4.0 has a higher priority right now. UDT enhancements will have to wait a bit longer.

11. Re: destructor

• Posted by mattlewis (admin) Mar 15, 2009
• 943 views

Wait, I thought we were including this in 4.0, so we could garbage collect, e.g., maps. I just committed code to automatically GC regexesnot the currently built PCRE, though it should be easy enough to adapt what I've done to that, if we end up going that way.

Matt

13. Re: destructor

• Posted by DerekParnell (admin) Mar 15, 2009
• 921 views

Oh?! I misunderstood this then.

I thought that GC for maps in not a show stopper, as it can be done right now with a bit of extra work on the coders part, it did not think that this was a high priority even though it is an important enhancement. Also, as it is not a v3.1 code breaker I didn't think it was a must-do-now thing.

I'll send you a note on the dev-list with my thoughts on UDT ctor/dtor functionality.

15. Re: destructor

• Posted by DerekParnell (admin) Mar 15, 2009
• 980 views

I can't see how the usage will change? Can you give me an example of what you mean?

A typical usage of map would go something like ...

    custrec = new() -- Create a new map 
    . . . 
    put(custrec, "Name", "Joe Blow") 
    put(custrec, "Address", "555 High Street") 
    put(custrec, "Phone", 555675632) 
    . . . 
    name = get(custrec, "Name") 
    . . . 
    delete(map) 

And stacks are the same thing.

PBR will not force this usage to change, as far as I can see. The underlying implementation will change but the API shouldn't have to change. What am I overlooking? I know that the delete() call might be superfluous in most cases but its not wrong.

17. Re: destructor

• Posted by DerekParnell (admin) Mar 15, 2009
• 949 views

Exactly. We will no longer HAVE to call delete(), but doing so is not actually wrong or going to cause a problem.

We need an explicit delete mechanism because sometimes one needs to delete a map/whatever before it goes out of scope.

All I'm saying is that PBR and UDT dtors are not essential to having v4.0 ship.

19. Re: destructor

• Posted by jeremy (admin) Mar 15, 2009
• 931 views
• Last edited Mar 16, 2009

Hm, I'm not sure I've ever had to do that in any other language. I simply put the map in the scope that it's valid. I do know sometimes you may need to clear a map, but that's not the same as deleting it's very existence, but further, one should not have to clear/delete a map when they are done using it for 4.0 and then no longer have to for 4.1. I think this teaching of the users just for 4.0 is not wise. Euphoria takes care of it's own memory and does not require the user to do so. If we do not have UDT's in 4.0 then this is no longer the case. Users will then have to learn about memory management, and for just one version? When 4.1 comes out, not having to do it? (ok, they could still do it if they wanted, but in 4.1 it would be the rare exception, not the norm like you are suggesting they have to do in 4.0).

Personally, if it came down to UDT's not in 4.0, I think it would be wiser to not ship map/stack and introduce them in 4.1 when UDT's or PBR is in Euphoria.

I'm not yet convinced, but I'm not the sole decision maker on these things, maybe we need to discuss it on the dev list amongst the other developers and vote on this?

Jeremy