1. Variable Arguments?
- Posted by Jeremy Cowgar <jeremy at c??gar.com> Apr 20, 2008
- 678 views
Aku has mentioned in the past about Euphoria and variable arguments. Does someone know if this is a huge or small change to the core? I am not certain as I have not yet studied the internal workings of Euphoria. I have glanced, but not studied. A few examples were brought about, such as the function round(). Since no variable arguments exist, a 2nd function has to be created called round_prec() (or round precision).
result = round({1.3, 2.1, 5.7}) result = round_prev({1.3432, 5.3232, 8.294833}, 10)
Any thoughts from those that know the internals? -- Jeremy Cowgar http://jeremy.cowgar.com
2. Re: Variable Arguments?
- Posted by Matt Lewis <matthewwalkerlewis at g?ail?com> Apr 20, 2008
- 640 views
- Last edited Apr 21, 2008
Jeremy Cowgar wrote: > > Aku has mentioned in the past about Euphoria and variable arguments. Does > someone > know if this is a huge or small change to the core? I am not certain as I have > not yet studied the internal workings of Euphoria. I have glanced, but not > studied. I did some thinking about this a while back (I recall having a discussion with Pete L). I don't recall details, but I think it would be a pretty involved change. > A few examples were brought about, such as the function round(). Since no > variable > arguments exist, a 2nd function has to be created called round_prec() (or > round > precision). In cases like the rounding, the added name probably makes sense. In other cases, we can use atom vs sequence to get the effect. For creating widgets in wxEuphoria, I use optional arguments through a sequence. It actually works pretty well. Matt
3. Re: Variable Arguments?
- Posted by CChris <christian.cuvier at ?griculture.gouv.?r> Apr 21, 2008
- 625 views
Jeremy Cowgar wrote: > > Aku has mentioned in the past about Euphoria and variable arguments. Does > someone > know if this is a huge or small change to the core? I am not certain as I have > not yet studied the internal workings of Euphoria. I have glanced, but not > studied. > > A few examples were brought about, such as the function round(). Since no > variable > arguments exist, a 2nd function has to be created called round_prec() (or > round > precision). > > }}} <eucode> > result = round({1.3, 2.1, 5.7}) > result = round_prev({1.3432, 5.3232, 8.294833}, 10) > </eucode> {{{ > > Any thoughts from those that know the internals? > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> Defaulted arguments are implemented in Æ (Advanced Euphoria), which needs further testing before I ever release it. So, obviously, I'm 150% favorable to it. CChris
4. Re: Variable Arguments?
- Posted by Jeremy Cowgar <jeremy at cow?a?.com> Apr 21, 2008
- 632 views
CChris wrote: > > Defaulted arguments are implemented in Æ (Advanced Euphoria), which needs > further > testing before I ever release it. So, obviously, I'm 150% favorable to it. > Default arguments would be just as good.
global function round(sequence nums, integer precision=1) .... end function data = round({1.4, 4,3}) data = round({5.48574, 3.43283}, 100)
Was that a difficult change? What is Advanced Euphoria? -- Jeremy Cowgar http://jeremy.cowgar.com
5. Re: Variable Arguments?
- Posted by Jeremy Cowgar <jeremy at c?wga?.com> Apr 21, 2008
- 645 views
Jeremy Cowgar wrote: > > CChris wrote: > > > > Defaulted arguments are implemented in Æ (Advanced Euphoria), which needs > > further > > testing before I ever release it. So, obviously, I'm 150% favorable to it. > > In fact, default arguments would be preferred over variable arguments to me. -- Jeremy Cowgar http://jeremy.cowgar.com
6. Re: Variable Arguments?
- Posted by CChris <christian.cuvier at ?griculture.?ouv.fr> Apr 21, 2008
- 656 views
Æ comes from a longstanding reluctance from a small group on this list to allow coders to do commonplace things in a simple way using Eu. I ended up starting my own fork from the interpreter. The change was not trivial because it involves the ability to replay canned tokens after recording them. Indeed procedure foo(integer n=n0) needs late binding, since what n0 is depends on the context of each call to foo(). Since this internal feature made other enhancements possible, I called the change worthwhile. As I mentioned earlier, I have other thingsto do, and this project has dropped to lower priority. I still plan to release it someday. Long term plans include a move to an hybrid JIT/interpreted design, which would perhaps remove the need for a translator, and at the same time the very frustrating limitations the latter imposes on what Eu can do. Indeed, Eu has the drawbacks of an interpreted language, and ties itself up by adding the constraints of compiling translated C code. This doesn't make sense, I think. Compatibility with Eu will probably decrease from 100 to 90-95% because some basic design flaws will be eliminated. As you can expect, there is no tiùetable for that part. CChris Jeremy Cowgar wrote: > > CChris wrote: > > > > Defaulted arguments are implemented in Æ (Advanced Euphoria), which needs > > further > > testing before I ever release it. So, obviously, I'm 150% favorable to it. > > > > Default arguments would be just as good. > > }}} <eucode> > global function round(sequence nums, integer precision=1) > .... > end function > > data = round({1.4, 4,3}) > data = round({5.48574, 3.43283}, 100) > </eucode> {{{ > > Was that a difficult change? What is Advanced Euphoria? > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
7. Re: Variable Arguments?
- Posted by Jeremy Cowgar <jeremy at cowga?.?om> Apr 21, 2008
- 647 views
CChris wrote: > > The change was not trivial because it involves the ability to replay canned > tokens after recording them. Indeed > procedure foo(integer n=n0) > needs late binding > Even something as simple as:
procedure foo(opt object n)
and if n was not supplied, n defaulting to NULL would be a huge step.
function round(sequence items, opt object n) if n = NULL then n = 1 end if ... code for round_precision ... end function
That's not as good as function round(sequence items, integer precision=1) but, it's a huge step above what we have now and could be maintained later once an assignment would be possible. How hard is something like that? -- Jeremy Cowgar http://jeremy.cowgar.com
8. Re: Variable Arguments?
- Posted by CChris <christian.cuvier at agricultur?.gouv?fr> Apr 21, 2008
- 638 views
- Last edited Apr 22, 2008
Jeremy Cowgar wrote: > > CChris wrote: > > > > The change was not trivial because it involves the ability to replay canned > > tokens after recording them. Indeed > > procedure foo(integer n=n0) > > needs late binding > > > > Even something as simple as: > > }}} <eucode> > procedure foo(opt object n) > </eucode> {{{ > > and if n was not supplied, n defaulting to NULL would be a huge step. > > }}} <eucode> > function round(sequence items, opt object n) > if n = NULL then n = 1 end if > ... code for round_precision ... > end function > </eucode> {{{ > > That's not as good as function round(sequence items, integer precision=1) but, > it's a huge step above what we have now and could be maintained later once an > assignment would be possible. > > How hard is something like that? > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> What is NULL? If we had a nil object, as I have advocated for a long time, then it would be ok. But adding nil is trickier I think - or not, I haven't tried yet. Moving to 3-way logic might break too much code. CChris
9. Re: Variable Arguments?
- Posted by Matt Lewis <matthewwalkerlewis at g?ail.c?m> Apr 21, 2008
- 626 views
- Last edited Apr 22, 2008
CChris wrote: > > Long term plans include a move to an hybrid JIT/interpreted design Yeah, this would be awesome. I actually had a .NET version of ooeu (well, it still exists, but I haven't done anything with it). The problem I had was dealing with the fluidity of integers and atoms. Anything that the interpreter couldn't determine was an integer was extremely slow. Still, pretty cool. Matt
10. Re: Variable Arguments?
- Posted by c.k.lester <euphoric at ckle?ter?com> Apr 21, 2008
- 634 views
- Last edited Apr 22, 2008
Matt Lewis wrote: > CChris wrote: > > Long term plans include a move to an hybrid JIT/interpreted design > Yeah, this would be awesome. Just curious... what's the benefit/difference from what we have now?
11. Re: Variable Arguments?
- Posted by CChris <christian.cuvier at agriculture.??uv.fr> Apr 22, 2008
- 651 views
c.k.lester wrote: > > Matt Lewis wrote: > > CChris wrote: > > > Long term plans include a move to an hybrid JIT/interpreted design > > Yeah, this would be awesome. > > Just curious... what's the benefit/difference from what we have now? Look at how the source translates to machine code: 1/ it is parsed into a huge hash table2/ 2/ at the same time, bytecode, aka IL, is being generated and put into that table. 3/ The table is read again and compressed, for the backaned to execute a flow of IL usng as little side info as possible 4/ The bytecode is turned into machine code in the backend, each chunk being executed independently of the neighboring ones. Good recipe for ache misses and execution penalties. Also, the backend does some more conversion/reformatting of the reduced data the front end handed to it. The idea is plainly to eliminate step 3 and optimise step 4. At the same time, it would become far easier to have front end and back end cooperating to execute dynamically created code - at a performance cost for that code, of course. Also, since the speed would be much closer to C's, the translator could probably be phased out, with the benefits I mentioned in an earlier post. So, it would be very different under the hood, and would boost both the flexibility and usability of the language, besides performance. Only glitch: since an assembly kernel would be there, porting to other CPUs will be harder. But Eu isn't ported a lot anyway. There would still be a C coded I/O module, so as to accommodate various OSes on a given architecture. This is a huge project and I won't embark in it alone. CChris
12. Re: Variable Arguments?
- Posted by c.k.lester <euphoric at ?kle?ter.com> Apr 22, 2008
- 650 views
CChris wrote: > c.k.lester wrote: > > Matt Lewis wrote: > > > CChris wrote: > > > > Long term plans include a move to an hybrid JIT/interpreted design > > > Yeah, this would be awesome. > > Just curious... what's the benefit/difference from what we have now? > Look at how the source translates to machine code: <snipped> > The idea is plainly to eliminate step 3 and optimise step 4. At the same time, > it would become far easier to have front end and back end cooperating to > execute > dynamically created code - at a performance cost for that code, of course. So the benefit is to get the ability to execute dynamically generated code. > So, it would be very different under the hood, and would boost both the > flexibility > and usability of the language, besides performance. How would the language become more flexible/usable? Executing dynamic code, or is there more to it? > Only glitch: since an assembly > kernel would be there, porting to other CPUs will be harder. But Eu isn't > ported > a lot anyway. There's a point in market saturation where porting would probably jump exponentially. Would we reach that point of market saturation by making the changes suggested? Can't the assembly kernel be made cross platform, or is it hooking into the OS too rigidly?
13. Re: Variable Arguments?
- Posted by Jeremy Cowgar <jeremy at co?g?r.com> Apr 22, 2008
- 649 views
CChris wrote: > > Also, since the speed would be much closer to C's, the translator could > probably be phased out, with the benefits I mentioned in an earlier post. > Hm, the translator not only benefits speed but makes distribution of resulting applications *very* easy. I would really hate to see that go. -- Jeremy Cowgar http://jeremy.cowgar.com
14. Re: Variable Arguments?
- Posted by yuku <yuku at ?k?tek.com> Apr 22, 2008
- 622 views
CChris wrote: > > Jeremy Cowgar wrote: > > > > CChris wrote: > > > > > > The change was not trivial because it involves the ability to replay > > > canned > > > tokens after recording them. Indeed > > > procedure foo(integer n=n0) > > > needs late binding > > > > > > > Even something as simple as: > > > > }}} <eucode> > > procedure foo(opt object n) > > </eucode> {{{ > > > > and if n was not supplied, n defaulting to NULL would be a huge step. > > > > }}} <eucode> > > function round(sequence items, opt object n) > > if n = NULL then n = 1 end if > > ... code for round_precision ... > > end function > > </eucode> {{{ > > > > That's not as good as function round(sequence items, integer precision=1) > > but, > > it's a huge step above what we have now and could be maintained later once > > an > > assignment would be possible. > > > > How hard is something like that? > > > What is NULL? > If we had a nil object, as I have advocated for a long time, then it would be > ok. But adding nil is trickier I think - or not, I haven't tried yet. Moving > to 3-way logic might break too much code. Instead of having a variable arguments or null type, I agree with JCougar, having default arguments will be easier to understand and easier to implement. How about this syntax (as intuitive as possible) [global] {function|procedure} <name> ( [<type> <name>]* [<type> <name> = <def>]* ) where <def> indicates default argument and it must be a constant! Default arguments also must be the last in the argument list. Then, instead of modifying the back end, we can only modify the front end, to make it act like a preprocessor. e.g. for
global function round(object item, integer prec = 0)
, if the call is like round(2.54), the front-end will emit IL that is exactly the same as if the code were round(2.54, 0). yuku
15. Re: Variable Arguments?
- Posted by CChris <christian.cuvier at agricult?re.gouv.?r> Apr 23, 2008
- 634 views
c.k.lester wrote: > > CChris wrote: > > c.k.lester wrote: > > > Matt Lewis wrote: > > > > CChris wrote: > > > > > Long term plans include a move to an hybrid JIT/interpreted design > > > > Yeah, this would be awesome. > > > Just curious... what's the benefit/difference from what we have now? > > Look at how the source translates to machine code: > > <snipped> > > > The idea is plainly to eliminate step 3 and optimise step 4. At the same > > time, > > it would become far easier to have front end and back end cooperating to > > execute > > dynamically created code - at a performance cost for that code, of course. > > So the benefit is to get the ability to execute dynamically generated code. > > > So, it would be very different under the hood, and would boost both the > > flexibility > > and usability of the language, besides performance. > > How would the language become more flexible/usable? Executing dynamic code, > or is there more to it? > It would be much easier to extend by features which boost usability:: * runtime error handling (possiby with resume) * "intelligent" routine calls, for instance ability to know who called current routine * ... Since those are hard to implement in a compiled language, they cannot be handled by the translator and, as a result, cannot currenly benefit Eu. > > Only glitch: since an assembly > > kernel would be there, porting to other CPUs will be harder. But Eu isn't > > ported > > a lot anyway. > > There's a point in market saturation where porting would probably jump > exponentially. Would we reach that point of market saturation by making the > changes suggested? I don't know. For starters, I'm not sure of how many different architectures are to be contemplated. > > Can't the assembly kernel be made cross platform, or is it hooking into the > OS too rigidly? The assembly kernel depends on the family of CPUs which it targets. Interactions with the OS will be handled by a module written in C, which can be rebuilt to accommodate any OS for which there is a C library available. That module may well be a repackaging of the current backend code that deals with the OS. The assembly kernel would call that module in a cross OS way, and it is thought of the OS-agnostic part of the backend. Lots of details aren't worked out yet, this is only a blueprint. CChris
16. Re: Variable Arguments?
- Posted by CChris <christian.cuvier at agri?ulture?gouv.fr> Apr 23, 2008
- 631 views
Jeremy Cowgar wrote: > > CChris wrote: > > > > Also, since the speed would be much closer to C's, the translator > could probably be phased out, with the benefits I mentioned in an earlier > post.</font></i> > > > > Hm, the translator not only benefits speed but makes distribution of resulting > applications *very* easy. I would really hate to see that go. > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> It would not need to go, but would no longer be a part of the core distribution. It would become a *very* useful appliation, not less, no longer more. CChris
17. Re: Variable Arguments?
- Posted by Jeremy Cowgar <jeremy at cow?ar.co?> Apr 23, 2008
- 772 views
CChris wrote: > > > > Hm, the translator not only benefits speed but makes distribution of > > resulting > > applications *very* easy. I would really hate to see that go. > > > It would not need to go, but would no longer be a part of the core > distribution. > It would become a *very* useful appliation, not less, no longer more. > One huge benefit I see to Euphoria is the ease of doing this. For instance, write a complex app in Ruby, Python or Perl then try to give it to someone to use who barely knows how to use Email. Sure, programs exist to make exe's out of them, but give them a try and see how well they work. In Euphoria it's cake! Why would it no longer be part of the core? -- Jeremy Cowgar http://jeremy.cowgar.com
18. Re: Variable Arguments?
- Posted by CChris <christian.cuvier at ag?iculture.gouv.f?> Apr 23, 2008
- 669 views
yuku wrote: > > CChris wrote: > > > > Jeremy Cowgar wrote: > > > > > > CChris wrote: > > > > > > > > The change was not trivial because it involves the ability to replay > > > > canned > > > > tokens after recording them. Indeed > > > > procedure foo(integer n=n0) > > > > needs late binding > > > > > > > > > > Even something as simple as: > > > > > > }}} <eucode> > > > procedure foo(opt object n) > > > </eucode> {{{ > > > > > > and if n was not supplied, n defaulting to NULL would be a huge step. > > > > > > }}} <eucode> > > > function round(sequence items, opt object n) > > > if n = NULL then n = 1 end if > > > ... code for round_precision ... > > > end function > > > </eucode> {{{ > > > > > > That's not as good as function round(sequence items, integer precision=1) > > > but, > > > it's a huge step above what we have now and could be maintained later once > > > an > > > assignment would be possible. > > > > > > How hard is something like that? > > > > > What is NULL? > > If we had a nil object, as I have advocated for a long time, then it would > > be > > ok. But adding nil is trickier I think - or not, I haven't tried yet. Moving > > to 3-way logic might break too much code. > > Instead of having a variable arguments or null type, I agree with JCougar, > having default arguments will be easier to understand and easier to implement. > > How about this syntax (as intuitive as possible) > > [global] {function|procedure} <name> ( [<type> <name>]* [<type> <name> = > <def>]* > ) > > where <def> indicates default argument and it must be a constant! > Default arguments also must be the last in the argument list. > > Then, instead of modifying the back end, we can only modify the front end, > to make it act like a preprocessor. e.g. for > }}} <eucode> > global function round(object item, integer prec = 0) > </eucode> {{{ > > , if the call is like round(2.54), the front-end will emit IL that is > exactly the same as if the code were round(2.54, 0). > > > yuku But call_func(routine_id("round"),{2.54}) will need handling at runtime, ie in backend. CChris
19. Re: Variable Arguments?
- Posted by CChris <christian.cuvier at agricultur?.go?v.fr> Apr 23, 2008
- 644 views
Jeremy Cowgar wrote: > > CChris wrote: > > > > > > > Hm, the translator not only benefits speed but makes distribution of > > > resulting > > > applications *very* easy. I would really hate to see that go. > > > > > It would not need to go, but would no longer be a part of the core > > distribution. > > It would become a *very* useful appliation, not less, no longer more. > > > > One huge benefit I see to Euphoria is the ease of doing this. For instance, > write a complex app in Ruby, Python or Perl then try to give it to someone to > use who barely knows how to use Email. Sure, programs exist to make exe's out > of them, but give them a try and see how well they work. > > In Euphoria it's cake! Why would it no longer be part of the core? > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> So as not to hamper development of the language. In the past, U thought that RDS idea that the Translator should be consistent with everything else to be a good idea. But there are many useful featres it will never handle, and this is keeping them out. Then there are three routes: * not to have them (easiest, helps the language stagnate); * not to have them in translator: this change of policy might not fly; * do away with translator as core component, and go forward. But Eu as it stans now can hardly do away with the trannslator. Since there are some issues which are also hampering usability of the language, like no complete encapsulation, awkward mutual calling of routines, integers that behave in a very unique way, etc), my plan is to deal with them all at once. To do that requires to streamline the source to machine code process, and that's what I was outlining. CChris