[M3devel] set operations parse.c?

[Tony Hosking]

On 4 Mar 2010, at 01:55, Jay K wrote:

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

Why hide simple code behind a contorted flag-driven procedure abstraction?

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

They don't require calling context to understand what they mean.

> 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.

Too much work for the front-end.  It shouldn't have to worry about such things.

> 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/a91a4d7b/attachment-0002.html>