Euphoria Ticket #202: type handling request

A type check error may occur in a type check handler itself.

type list(sequence s) 
     if length(s)!=2 or compare(s[2],0) or not list(s[2]) then 
          return 0 
     end if 
     return 1 
end type 

Now if you do:

list bar = 0 

We have a type check failure at the top of the type function, for 0 is not a sequence. I think we all want this. However, when we call the type checking function I think it would be a good thing to have list() return 0 from the function instead of crashing when a type-check failure is triggered inside list().

Take this example code:

if list(foo) then 
   puts(1,"0 is not a list\n") 
end if 

list can return 0, 1 or die in a type-check failure if foo is an atom. The feature request is we change this behavior, via some kind of with statement, such that a type-check error exception inside list() would result in list() returning 0 when list is called as a function.


Type: Feature Request Severity: Normal Category: Interpreter
Assigned To: unknown Status: New Reported Release: 3412
Fixed in SVN #: View VCS: none Milestone: 5.0.0

1. Comment by mattlewis Sep 15, 2010

My initial take on this is that I'm against it, though I haven't fully thought through it. Consider the way it currently works:

        [shawn.ex:9] list foo = 0 (9) 
     1: 018 138 156                      # [LIT 0:138] => [foo:156] 
     4: 027 142 156 157                  # FUNC: [list:142][foo:156] => [_temp_:157] 
     8: 065                              # TYPE_CHECK: 
     9: 087 156                          # DISPLAY_VAR: [foo:156]  
        [shawn.ex:11] ? list( 0 ) (11) 
    11: 058 11                           # STARTLINE: shawn.ex(11)<<? list( 0 )>> 
    13: 027 142 138 158                  # FUNC: [list:142][LIT 0:138] => [_temp_:158] 
    17: 089                              # UPDATE_GLOBALS: 
    18: 036 137 158                      # QPRINT: [_temp_:158] 

Both the type check call and the function call are just function calls. We check the return in the case of a true type check. I suppose that when implementing a type check, we'd have to know if we were currently in a type checked routine (probably need a new opcode to set a flag that we push onto the call stack or something). Then, if not, instead of crashing, we return 0 from the function.

Since the "workaround" for doing this is so simple, I'm having a hard time justifying this to myself.

2. Comment by SDPringle Sep 17, 2010

The argument was made on the developer's list. When objects that are being type-checked become large and complex this feature would be useful. Take the example of a sequence of lines:

type sequence_of_lines(object x) if atom(x) then

3. Comment by SDPringle Sep 17, 2010

The argument was made on the developer's list. Good reasons too, look what happens when I write code in my browser. I press TAB and then space and it updates the ticket. Please refer to what I posted there as a response.

4. Comment by mattlewis Sep 17, 2010

I vaguely recall discussing this issue before, but you're not being very persuasive here. At least provide a link to the thread. And tell me why the workaround isn't good enough.

Thinking more about it, I'm not entirely happy about weakening type checking even more so that even when with type_check is in effect, sometimes it isn't.

5. Comment by jimcbrown Sep 18, 2010

I think that, in the future, this will be a lot easier to implement more cleanly, with less effort, and probably without a performance hit. (But if there is a performance hit, we can still fix it via with/without statements.)


type x(sequence s) catches TypeCheckFailureException 
	catch -- this also catches the TypeCheckFailureException that the  
		-- type declaration promised to catch above 
		return 0 
	end try 
end type 

Disagree with the syntax? Fine. But my point is, this will be a lot easier to do right in a version of Euphoria that has real exception handling.

Right now, it's too complicated to implement cleanly. So let's wait until we can do it right.

6. Comment by jimcbrown Nov 09, 2010

Moving to 5.0.0 Milestone (i.e. when/if we implement exception handling).


Quick Links

User menu

Not signed in.

Misc Menu