[M3devel] set operations parse.c?

[Jay K]

Any reuse is too obscuring and not worthwhile if the functions already fit on a page?

Huh.

 

 

By that metric, setop, setop2, m3cg_set_compare aren't needed either.

Actually I do find setop vs. setop2 a *little* hard to read.

And I hope to soon get rid of two out of its three uses pretty soon (set_singleton, member), maybe tonight.

 

 

The relationship between eq and ne seems among the strongest, except for all the other comparisons.

 

 

Actually I'm not sure I "like" a lot here.

There is or can be enough similarity in the backends, that the frontend probably should just generate either inline code or calls to portable Modula-3 functions, at least lt/le/gt/ge, and to memcmp for eq/ne.

singleton/member I'm a bit on the fence.

They can be generated portably inline with pretty small code, though that'd take away the ability of m3back to easily know to use bt/bts instructions.

 

 

You know, my big "fight" is with "too much code". Anything that the frontend can do pretty darn well, is better than doing it in multiple backends. "More higher level operations" are most useful so a "simpler" backend, such as m3back but not gcc, can more easily generate better code.

 

 

 - Jay
 





Subject: Re: set operations parse.c?
From: hosking at cs.purdue.edu
Date: Wed, 3 Mar 2010 22:27:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu





It obscures the simple intent of the eq/ne operations, and conflates them with other similarly simple set operations.


Agreed, the implementations now vary in only one token, but I can read them each in a single page of my editor and validate their correctness without having to trace through multiple calls and track a flag value in context along the way.


On 3 Mar 2010, at 19:45, Jay K wrote:


The flag to setop is maybe yucky, but I think
 static void m3cg_set_eq (void) { m3cg_set_eq_or_ne(EQ_EXPR); }   
 static void m3cg_set_ne (void) { m3cg_set_eq_or_ne(NE_EXPR); } 

 
is still good.
There are two functions *very* similar in functionality that vary in only one token.
 
 
The counterpoint would be, perhaps, if one is proficient enough
in maintaining parse.c, that the two functions are small and
one could write them up in a flash without referring to examples.



EXACTLY!


One needs that level of proficiency to make more significant changes anyway.
(I'll be removing the set_singleton/member functions shortly, assuming
reasonable codegen.)
 

 - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100304/da5cf309/attachment-0002.html>