建议增加“公式串接”函数

lshhaaa

建议增加“公式串接”函数，功能类似c语言的“#include”，（下面简称“本函数”）

希望实现的功能：在编译阶段之初，把常用模块，自动插入（嵌入）到主策略公式中，和主程序融为一体，然后再进行统一编译。
（可以看作是：一个策略公式，其代码分别放在多个策略公式中，编译前自动合并拼接在一起。）


具体建议的细节如下：
1、本函数是调用公式，不是调用文件。（c语言的“#include”是调用文件）。
2、与 “#.#”函数的区别：#.#是在运行中调用其它模块，且被调用模块的每一行并非全部执行（不能在被调用模块执行买卖、划线等语句，而本函数可弥补此不足）。
3、本函数用法比如：“include 用户函数名称”。
4、使用本函数，编译时自动把“用户函数”的参数，叠加在主程序的参数列表后。
5、被调用公式可以单独不断优化改进，此时主程序不需改动（仅需编译）即可实现同步升级。


本函数实现拼接代码功能，看似简单，却非常实用，在模块化方面与“#.#”相得益彰，期盼早日看到此改进，谢谢！

技术006

抱歉，暂不考虑这类需求。

lshhaaa

技术006 发表于 2021-12-7 09:45
抱歉，暂不考虑这类需求。

感谢回复，是否我写的文字太多让你有些误会呢？
这个建议仅仅提出了“拼接代码”的功能，理应没有难度，但效果却很好，
而直接否定，就中断了继续讨论此类“高性价比”建议的可行性，
很遗憾。

另外请问：你写的“这类需求”是指哪些范围？是指关于函数的建议吗？请明示，
如果是的话，以后用户回避提函数方面的建议即可。

2021年11月27日魏巍老板在群中发言，问群友有哪些函数方面的改进可以借鉴，
可能我误会了，以为你们的函数优化是开放的、持续的。

技术006

就是你上头所说的函数拼接需求。这类需求会牵扯到pel的整个机制。

技术015

这个模式没看到能比用户函数 #.# 模式有更高的效率体现的，还是一样编译在原先公式中，即起不到提高效率，反而增大了编译时间

lshhaaa

技术015 发表于 2021-12-7 12:37
这个模式没看到能比用户函数 #.# 模式有更高的效率体现的，还是一样编译在原先公式中，即起不到提高效率， ...

感谢回复！
诚如你所言，改进后编译效率、运行效率均未提高，
但这两方面本来也不是模块化所追求的目标。
模块化的优点巨大，本帖无须讨论，其它流行编程语言大多做到了尽可能的模块化。
而PEL在模块化方面存在短板，如上面提到的#.#无法执行每一行等。
局限于个人对PEL深层次的理解，如技术006客服所言，若增加本函数将改动PEL机制的话，我肯定首先反对改动，因为改动将带来更多不稳定和bug。

既然是建议，当然属于锦上添花、可采取也可不采取的范畴。
作为从分析家、飞狐、金字塔一路走来的PEL热心爱好者，只是希望它越来越好，
不发牢骚只提建议，所提建议均反复推敲并慎重提出，务求描述准确以至于字数较多，阅读不便。望包涵

技术008

理解您说的巨大好处，但一个很显然的问题，流行计算机编程语言那是专门给计算机编程使用
pel毕竟不是做这个事情的，妄图让pel增加很多专业计算机的功能，那么和直接使用我们提供的vba python c++有啥区别呢

包括你上面提到的，那么我们也可以考虑增加面向对象了不是吗