problem localized:

restart;
MakeComp:=proc(pin::procedure) global h; local lp1::procedure, lp2;
  lp1:=eval(Compiler:-Compile(pin));
  lp2:=u->eval(lp1(u));
  return lp2;
end proc:
gp:=proc(x::float)::float; return x^2; end proc:
gp_via_local_cover:=MakeComp(gp):
gp_via_global_cover:=u->eval(gp_via_local_cover(u)):
evalhf(gp_via_local_cover(1.0));
Error, lexical scoping is not supported in evalhf
evalhf(gp_via_global_cover(1.0));
1.
Is local eval-cover for non-evalhf possible? For this moment only global one works.

"That says: you may want to test before asking."

WHAT?

try run

MainF(1.0,2.0,8.0);
MainF(1.0,2.0,9.0);

different results, are they? So what constant are you talking about?

And of course function result expect to be constant. Otherwise what sense to test it to evalhf?

MainF(_x, _y, _z) one gets "Error, invalid input: MainF expects
its 1st argument, u, to be of type float, but received _x"

Of course, what else do you expect from fuction with directly typed arguments that also call a pair of other COMPILED functions with float arguments.

"As already said: first ensure that the basic Maple code..."

This is a basic. Step left, step right - bullet in head. That's maple for me now.

Anyway i simplified as much as possible to do it at least worked. It includes:
1)  RationalToFloat accordingly that issue with which i faced too.

2) Typizations of parameters after completly lost of them types after optimize call accordingly to branch annswer to your question in same link.

So, please, consider question more deeply because i will not overcome it by myself, maple really kills me :(

Attach : ex.mw

"That says: you may want to test before asking."

WHAT?

try run

MainF(1.0,2.0,8.0);
MainF(1.0,2.0,9.0);

different results, are they? So what constant are you talking about?

And of course function result expect to be constant. Otherwise what sense to test it to evalhf?

MainF(_x, _y, _z) one gets "Error, invalid input: MainF expects
its 1st argument, u, to be of type float, but received _x"

Of course, what else do you expect from fuction with directly typed arguments that also call a pair of other COMPILED functions with float arguments.

"As already said: first ensure that the basic Maple code..."

This is a basic. Step left, step right - bullet in head. That's maple for me now.

Anyway i simplified as much as possible to do it at least worked. It includes:
1)  RationalToFloat accordingly that issue with which i faced too.

2) Typizations of parameters after completly lost of them types after optimize call accordingly to branch annswer to your question in same link.

So, please, consider question more deeply because i will not overcome it by myself, maple really kills me :(

Attach : ex.mw

In other branch answer goes in right place. Suspect that this is only problem of first branch i.e. problem of first index in array

@Axel Vogt 

I quit understand that myint doesn't compile. That situation i called bridge. While others i called "pure symbilic". The problem is  that bridges should have type of functions while "pure symbolic" are actually expressions. Bridges we can overcome via bridged function  (which are even not compiled at all). while "pure s" could be proceeded directly. If for example symbolic expression includes LerchPhi call then it compiled to external maple LerchPhi too like myint in this example but don't need that functional bridge, so LerchPhi is part of "pure s" too. For now i actually have only problem with int because only of range-like argument. If i could change DYNAMICALLY all subexpressions of form int(f(x1...,xn,t), t=t1,t2) to smth like myint(f,t, t1,t2) and make maple not to expand myint during unapply call then work would be done completly. But i doubt on it that's why i rather think of implementation of dividing expression itself and compile only compilible part (for other part i don't need even compilation, will call it "as is").

@Axel Vogt 

I quit understand that myint doesn't compile. That situation i called bridge. While others i called "pure symbilic". The problem is  that bridges should have type of functions while "pure symbolic" are actually expressions. Bridges we can overcome via bridged function  (which are even not compiled at all). while "pure s" could be proceeded directly. If for example symbolic expression includes LerchPhi call then it compiled to external maple LerchPhi too like myint in this example but don't need that functional bridge, so LerchPhi is part of "pure s" too. For now i actually have only problem with int because only of range-like argument. If i could change DYNAMICALLY all subexpressions of form int(f(x1...,xn,t), t=t1,t2) to smth like myint(f,t, t1,t2) and make maple not to expand myint during unapply call then work would be done completly. But i doubt on it that's why i rather think of implementation of dividing expression itself and compile only compilible part (for other part i don't need even compilation, will call it "as is").

"One can not see what 'func_encaps' is - so you can not expect an answer."
???

From very 2nd line:

func_encaps:=proc(expr::evaln)
return Compiler:-Compile(unapply(expr,y::float,a::float, b::float),optimize);
end proc:

Code is totally complete. Copy-paste and you can see problem.

About big or small function H: i actually don't know what else to expect from maple. In parallel branch size matters. For small H typization wasn't necessary that's why answer wasn't so obvious.

RE: 'createcomp' I don't quite understand.

Need encapsulation. Nothing more.

Besides compilation of evalf(Int willl not work too.

For evaln thanks. Pure expression-part of task done.

RE: 'createcomp' I don't quite understand.

Need encapsulation. Nothing more.

Besides compilation of evalf(Int willl not work too.

For evaln thanks. Pure expression-part of task done.

It really cannot thats why such calls should be encapsulated in fuctions (not in expressions thought unfortunately)

For example this one works:

myint:= proc(a);
return int(exp(x^6), x=0.0..a);
end proc:

createcomp:=proc (f) local exprfunc::symbol;
return Compiler:-Compile(f);
end proc:

zzz:=(y::float,a::float, b::float)->myint(a): #intermediate encapsulation

s:=createcomp(zzz);

Warning, the function names {myint} are not recognized in the target language

That what i can get! zzz compiled to external call of myint. While int directly will not even will be compiled because of syntax error (.. in arguments range for definite integral). But i don't need that actually.  The question is actually then how to divide expression into 'compilible' and noncompilible parts.

It really cannot thats why such calls should be encapsulated in fuctions (not in expressions thought unfortunately)

For example this one works:

myint:= proc(a);
return int(exp(x^6), x=0.0..a);
end proc:

createcomp:=proc (f) local exprfunc::symbol;
return Compiler:-Compile(f);
end proc:

zzz:=(y::float,a::float, b::float)->myint(a): #intermediate encapsulation

s:=createcomp(zzz);

Warning, the function names {myint} are not recognized in the target language

That what i can get! zzz compiled to external call of myint. While int directly will not even will be compiled because of syntax error (.. in arguments range for definite integral). But i don't need that actually.  The question is actually then how to divide expression into 'compilible' and noncompilible parts.

restart;
func_encaps:=proc(expr::evaln)
return Compiler:-Compile(unapply(expr,y::float,a::float, b::float),optimize);
end proc:
H:=(2*(-a+6*y^2*a^2+2*b*y^2*a^2+9*b*y^3*a+3*b*y^2*a+b*y^6*a^2+4*b*y^5*a^2+5*b*y^4*a^2+2*b*y^5*a+8*b*y^4*a+3*b*y^3*a^2+4*b*y^2-y^3*a-3*y^2*a+y^6*a^3+5*y^5*a^3+8*y^4*a^3+4*y^3*a^3+y^5*a^2+5*y^4*a^2+9*y^3*a^2+b*y^4+4*b*y^3+y*a^2+2*a*b*y+y^3*a*(y+1)^(-2*b)+a*(y+1)^(-2*b)+3*y^2*a*(y+1)^(-2*b)+3*y*a*(y+1)^(-2*b)-2*y^2*a^2*(y+1)^(-2*b)-y*a^2*(y+1)^(-2*b)-3*y*a-y^3*a^2*(y+1)^(-2*b))/(y^2*(a+b)*(y+1)*(y+2)^2*(y*a+1)^2)+(-2-y^2+2*y^2*a^2-2*y+4*b*y^3*a+8*b*y^2*a+2*b*y^4*a^2+4*b*y^3*a^2+2*b*y^2+4*b*y+2*y^2*a+y^4*a^2+4*y^3*a^2+(y+1)^(-2*b)-2*y^2*a*(y+1)^(-2*b)-2*y*a*(y+1)^(-2*b)+y^2*a^2*(y+1)^(-2*b)+(y+1)^(-2*b)*y^2+2*(y+1)^(-2*b)*y+(y+1)^(-2*b-2)*y^2+2*(y+1)^(-2*b-2)*y+(y+1)^(-2*b-2)*y^4*a^2+2*(y+1)^(-2*b-2)*y^3*a+2*(y+1)^(-2*b-2)*y^3*a^2+4*(y+1)^(-2*b-2)*y^2*a+(y+1)^(-2*b-2)*y^2*a^2+2*(y+1)^(-2*b-2)*y*a+(y+1)^(-2*b-2))/(y^2*(a+b)*(y+2)^2*(y*a+1)^2))/((-a+6*y^2*a^2+2*b*y^2*a^2+9*b*y^3*a+3*b*y^2*a+b*y^6*a^2+4*b*y^5*a^2+5*b*y^4*a^2+2*b*y^5*a+8*b*y^4*a+3*b*y^3*a^2+4*b*y^2-y^3*a-3*y^2*a+y^6*a^3+5*y^5*a^3+8*y^4*a^3+4*y^3*a^3+y^5*a^2+5*y^4*a^2+9*y^3*a^2+b*y^4+4*b*y^3+y*a^2+2*a*b*y+y^3*a*(y+1)^(-2*b)+a*(y+1)^(-2*b)+3*y^2*a*(y+1)^(-2*b)+3*y*a*(y+1)^(-2*b)-2*y^2*a^2*(y+1)^(-2*b)-y*a^2*(y+1)^(-2*b)-3*y*a-y^3*a^2*(y+1)^(-2*b))^2/(y^4*(a+b)^2*(y+1)^2*(y+2)^4*(y*a+1)^4)-(1/4)*(-2-y^2+2*y^2*a^2-2*y+4*b*y^3*a+8*b*y^2*a+2*b*y^4*a^2+4*b*y^3*a^2+2*b*y^2+4*b*y+2*y^2*a+y^4*a^2+4*y^3*a^2+(y+1)^(-2*b)-2*y^2*a*(y+1)^(-2*b)-2*y*a*(y+1)^(-2*b)+y^2*a^2*(y+1)^(-2*b)+(y+1)^(-2*b)*y^2+2*(y+1)^(-2*b)*y+(y+1)^(-2*b-2)*y^2+2*(y+1)^(-2*b-2)*y+(y+1)^(-2*b-2)*y^4*a^2+2*(y+1)^(-2*b-2)*y^3*a+2*(y+1)^(-2*b-2)*y^3*a^2+4*(y+1)^(-2*b-2)*y^2*a+(y+1)^(-2*b-2)*y^2*a^2+2*(y+1)^(-2*b-2)*y*a+(y+1)^(-2*b-2))^2/(y^4*(a+b)^2*(y+2)^4*(y*a+1)^4)):
F:=unapply(H,y::float,a::float, b::float):
s:=Compiler:-Compile(F,optimize):
s2:=func_encaps(H):
s(1.0,2.0,3.0);
4.28730926684034230
s2(1.0,2.0,3.0);
Error, (in s2) global variable `H' expected to evaluate to a numeric, but found (2*(-y^3*a+y^6*a^3+y^5*a^2+b*y^4+y*a^2+a*(y+1)^(-2*b)+6*y^2*a^2+4*b*y^2-3*y^2*a+5*y^5*a^3+8*y^4*a^3+4*y^3*a^3+5*y^4*a^2+9*y^3*a^2+4*b*y^3-3*y*a-a+y^3*a*(y+1)^(-2*b)-y^3*a^2*(y+1)^(-2*b)-y*a^2*(y+1)^(-2*b)+b*y^6*a^2+2*b*y^2*a^2+9*b*y^3*a+3*b*y^2*a+4*b*y^5*a^2+5*b*y^4*a^2+2*b*y^5*a+8*b*y^4*a+3*b*y^3*a^2+2*a*b*y+3*y^2*a*(y+1)^(-2*b)+3*y*a*(y+1)^(-2*b)-2*y^2*a^2*(y+1)^(-2*b))/(y^2*(a+b)*(y+1)*(y+2)^2*(y*a+1)^2)+(-2+(y+1)^(-2*b)*y^2+(y+1)^(-2*b-2)*y^2+2*y^2*a^2+2*b*y^2+2*y^2*a+y^4*a^2+4*y^3*a^2+4*b*y+2*(y+1)^(-2*b)*y+2*(y+1)^(-2*b-2)*y-2*y+(y+1)^(-2*b-2)*y^4*a^2+(y+1)...

s works and s2 not. WTH? Has maple smth like macroses instead functions and could it help?

Just wonder, wheather i'm 1st with such kind of question? Noone need smth like that before?

Help to compile 's' expression!

main.mw

Thanks but it's rather minor change. For major ones i'm looking forward to have good results from Compiler:-Compile but for now i cannot even compile H itself in right way as i want. I mean

ggg:=unapply(H,y,a,b):
ggg2:=(y,a,b)->ggg(y,a,b):
s:=Compiler:-Compile(ggg2);

works with

Warning, the function names {ggg} are not recognized in the target language.

That means that compiled rather bridge to ggg than representation of H itself.

While 

ggg:=unapply(H,y,a,b):

s:=Compiler:-Compile(ggg);

it at least tried to comlpile H itself without success thought :(. And there is not only compiler fault. At least i don't understand why  it did argument change and... convert them to integer O_o:

cg3 = mrt_get_integer_arg( ___k___, (MRT_ARG( 1 )), 1, TYPE_NOSUCHTYPE );
cg = mrt_get_integer_arg( ___k___, (MRT_ARG( 2 )), 2, TYPE_NOSUCHTYPE );
cg1 = mrt_get_integer_arg( ___k___, (MRT_ARG( 3 )), 3, TYPE_NOSUCHTYPE );

I already installed new watcom compiler 1.9 and transmit all maple headers/lbraries there and added tmp directory. Without suceess :(