1. Variable Arguments?
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
-
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?
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?
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?
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?
Æ 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?
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
-
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
-
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
-
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?
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?
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?
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?
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?
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?
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?
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?
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?
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
