OpenEuphoria

1. Euphoria 2.5

• Posted by Bernard Ryan <xotron at bluefrog.com> Jul 27, 2004
• 697 views

Rob:
  When am I going to be able to spend my money
  for version 2.5 ?
Bernie

3. Re: Euphoria 2.5

• Posted by Derek Parnell <ddparnell at bigpond.com> Jul 28, 2004
• 648 views

Robert Craig wrote:
> 
> Bernard Ryan wrote:
> > Rob:
> >   When am I going to be able to spend my money
> >   for version 2.5 ?
> 
> I'm slowly working away at it.
> I took a big hit with the new "$" feature.

Yippee!!

[snip]

> but you shouldn't expect a release until September or October.

So long as its not November; I'll be way too busy with Halo 2 that month.

> The bigger this project gets, the longer it takes to make enhancements 
> to the code.

Tell me about it!

-- 
Derek Parnell
Melbourne, Australia

5. Re: Euphoria 2.5

• Posted by "Kat" <gertie at visionsix.com> Jul 28, 2004
• 610 views

On 28 Jul 2004, at 18:40, Igor Kachan wrote:

> 
> 
> Robert Craig wrote:
> 
> ----------
> > From: Robert Craig <guest at RapidEuphoria.com>
> > To: EUforum at topica.com
> > Subject: Re: Euphoria 2.5
> > Sent: 28 jul 2004 y. 7:53
> >
> > Bernard Ryan wrote:
> > > Rob:
> > >   When am I going to be able to spend my money
> > >   for version 2.5 ?
> > 
> > I'm slowly working away at it.
> > I took a big hit with the new "$" feature.
> > (s[$] = s[length(s)] etc.)
> > I thought it would be trivial to implement,
> > but it turned out I had to do a major overhaul
> > on all the subscripting code in the interpreter,
> > translator, and the new interpreter written 
> > in Euphoria.
> 
> What a problem, Rob?
> 
> Anyone can have that notorious feature just
> now and forever - do you remember:
> 
> }}}
<eucode>
> integer A_
> type sequence_with_length_A(sequence a)
>   A_= length(a)
>   return sequence(a)
> end type
> 
> sequence_with_length_A A_A
> 
> A_A = {}
> 
> ? A_
> 
> A_A = {1,2}
> 
> ? A_A[A_]
> </eucode>
{{{

> 
> > I've spent a lot longer than I expected, and
> > I'm still not quite finished. I think the feature
> > is definitely worth it, but you shouldn't expect 
> > a release until September or October.
> 
> This feature seems to be like same notorious
> "conditional dynamic include" - I still can not
> find the 3rd dynamic lover to drink that notorious
> Russian bottle of vodka for solved problem ...
> 65 EU countries ... Where is that 3rd?
> 
> It seems to me, Derek will search & look for 
> the 3rd $-lover too ...

I tend to agree. That $ merely saves a little typing, "goto" would be serious 
improvement to program flow.

Kat

7. Re: Euphoria 2.5

• Posted by "Igor Kachan" <kinz at peterlink.ru> Jul 28, 2004
• 626 views

CK Lester wrote:

----------
> From: cklester <guest at RapidEuphoria.com>
> To: EUforum at topica.com
> Subject: Re: Euphoria 2.5
> Sent: 28 jul 2004 y. 22:22
> 
> Igor, your version of s[length(s)] doesn't
> quite work perfectly...
> 
> Run this:
> -- start of code
> include get.e
> 
> sequence junk
> 
> integer A_
> type sequence_with_length_A(sequence a)
>   A_= length(a)
>   return sequence(a)
> end type
> 
> sequence_with_length_A A_A, A_B, A_C
> 
> A_A = "Hello"
> A_B = "World"
> A_C = "Goodbye!"
> 
> ?A_A[A_]
> ?A_B[A_]
> ?A_C[A_]
> 
> --end of code

He - he, CK, this version above is yours one,
it doesn't quite work perfectly...

> Sure, you could define B_ and C_, 

Yes, good, this is my version ...

> but what happens when you 
> have a billion sequences? :)

I'll use the next EU weapon against
a billion sequences ... :|

Oh God, give today our bread of today!

This phrase above is my translation of
the famous Orthodox prayer - "Hleb nash 
nasushnyj dazshd' nam dnes'!"

If you need some feature in October,
not today, you do not need it at all,
I think.

Regards,
Igor Kachan
kinz at peterlink.ru

9. Re: Euphoria 2.5

• Posted by cklester <cklester at yahoo.com> Jul 28, 2004
• 629 views

Igor Kachan wrote:
> 
> CK Lester wrote:
> > Igor, your version of s[length(s)] doesn't
> > quite work perfectly...
> > 
> > Run this:
> > -- start of code
> > include get.e
> > 
> > sequence junk
> > 
> > integer A_
> > type sequence_with_length_A(sequence a)
> >   A_= length(a)
> >   return sequence(a)
> > end type
> > 
> > sequence_with_length_A A_A, A_B, A_C
> > 
> > A_A = "Hello"
> > A_B = "World"
> > A_C = "Goodbye!"
> > 
> > ?A_A[A_]
> > ?A_B[A_]
> > ?A_C[A_]
> > 
> > --end of code
> 
> He - he, CK, this version above is yours one,
> it doesn't quite work perfectly...

No, it was your version with an example of why yours wouldn't work. :P

> > Sure, you could define B_ and C_, 
> 
> Yes, good, this is my version ...
> 
> > but what happens when you 
> > have a billion sequences? :)
> 
> I'll use the next EU weapon against
> a billion sequences ... :|

You mean you'll use '$' when necessary?

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

11. Re: Euphoria 2.5

• Posted by "Igor Kachan" <kinz at peterlink.ru> Jul 28, 2004
• 633 views

CK Lester wrote:

----------
> From: cklester <guest at RapidEuphoria.com>
> To: EUforum at topica.com
> Subject: Re: Euphoria 2.5
> Sent: 29 jul 2004 y. 0:39
> 
> Igor Kachan wrote:
> > 
> > CK Lester wrote:
> > > Igor, your version of s[length(s)] doesn't
> > > quite work perfectly...
> > > 
> > > Run this:
> > > -- start of code
> > > include get.e
> > > 
> > > sequence junk
> > > 
> > > integer A_
> > > type sequence_with_length_A(sequence a)
> > >   A_= length(a)
> > >   return sequence(a)
> > > end type
> > > 
> > > sequence_with_length_A A_A, A_B, A_C
> > > 
> > > A_A = "Hello"
> > > A_B = "World"
> > > A_C = "Goodbye!"
> > > 
> > > ?A_A[A_]
> > > ?A_B[A_]
> > > ?A_C[A_]
> > > 
> > > --end of code
> > 
> > He - he, CK, this version above is yours one,
> > it doesn't quite work perfectly...
> 
> No, it was your version with an example
> of why yours wouldn't work. :P

OK, yours example doesn't work, incorrect example. :b

> > > Sure, you could define B_ and C_, 
> > 
> > Yes, good, this is my version ...
> > 
> > > but what happens when you 
> > > have a billion sequences? :)
> > 
> > I'll use the next EU weapon against
> > a billion sequences ... :|
> 
> You mean you'll use '$' when necessary?

The next EU weapon is just old good EU ;)

I'd just copy/paste something billion times,
then correct code, maybe, I do not know,
I have no problem with length(s), I just use
that clear construct - s[length(s)].

These all examples show what a powerful and
flexible language EU is. 
Rob uses C to implement almost the same thing,
and it is not a trivial job, he says.

Regards,
Igor Kachan
kinz at peterlink.ru

13. Re: Euphoria 2.5

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 29, 2004
• 632 views

Igor Kachan wrote:

>> From: Juergen Luethje
>> Sent: 28 jul 2004 y. 23:39
>>
>> Igor Kachan wrote:
>>
>>> CK Lester wrote:
>>>>
>>>> Igor, your version of s[length(s)] doesn't
>>>> quite work perfectly...
>>>>
>>>> Run this:
>>>> -- start of code
>>>> include get.e
>>>>
>>>> sequence junk
>>>>
>>>> integer A_
>>>> type sequence_with_length_A(sequence a)
>>>>   A_= length(a)
>>>>   return sequence(a)
>>>> end type
>>>>
>>>> sequence_with_length_A A_A, A_B, A_C
>>>>
>>>> A_A = "Hello"
>>>> A_B = "World"
>>>> A_C = "Goodbye!"
>>>>
>>>> ?A_A[A_]
>>>> ?A_B[A_]
>>>> ?A_C[A_]
>>>>
>>>> --end of code
>>>
>>> He - he, CK, this version above is yours one,
>>> it doesn't quite work perfectly...
>>>
>>>> Sure, you could define B_ and C_,
>>>
>>> Yes, good, this is my version ...
>>
>> How should B_ and C_ be defined, and how
>>  should the appropriate value
>> be assigned to B_ and C_?
>> Will you define a separate type for each sequence?
>>
>> <snip>
>
> Yes,  a separate type for each sequence.
>
> }}}
<eucode>
> integer B_
> type sequence_with_length_B()
> ...
> end type
>
> integer C_
> type sequence_with_length_C()
> ...
> end type
>
> integer D_
> type sequence_with_length_D()
> ...
> end type
> </eucode>
{{{


And what is the advantage compared to conventional Euphoria programming
style, i.e. not using all those types, but using 'length(A_A)',
'length(A_B)' etc. directly?

Regards,
   Juergen

15. Re: Euphoria 2.5

• Posted by "Igor Kachan" <kinz at peterlink.ru> Jul 29, 2004
• 650 views

Hi Juergen,

[snipped old info]
> Igor Kachan wrote:
> >> From: Juergen Luethje
> >> Sent: 28 jul 2004 y. 23:39
> >> Igor Kachan wrote:
> >>> CK Lester wrote:
> >> How should B_ and C_ be defined, and how
> >>  should the appropriate value
> >> be assigned to B_ and C_?
> >> Will you define a separate type for each sequence?
> >>
> >> <snip>
> >
> > Yes,  a separate type for each sequence.
> >
> > }}}
<eucode>
> > integer B_
> > type sequence_with_length_B()
> > ...
> > end type
> >
> > integer C_
> > type sequence_with_length_C()
> > ...
> > end type
> >
> > integer D_
> > type sequence_with_length_D()
> > ...
> > end type
> > </eucode>
{{{

> 
> And what is the advantage compared 
>  to conventional Euphoria programming
> style, i.e. not using all those types,
> but using 'length(A_A)',
> 'length(A_B)' etc. directly?

Really you have just 1 or 2 main sequences in your program.
For example, ed.ex editor.
So, you can enter these types and then 
use A_  or  B_  anywhere you want instead of, say,
length(First_Very_Long_But_Very_Clear_Name_of_Main_Sequence_1)
and
length(Second_Very_Long_But_Very_Clear_Name_of_Main_Sequence_2).

But you could not use $-feature in the same manner,
there is no the separate $-value at all.

Regards,
Igor Kachan
kinz at peterlink.ru

17. Re: Euphoria 2.5

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 29, 2004
• 630 views

Hi Igor,

you wrote:

> Hi Juergen,
>
> [snipped old info]
>> Igor Kachan wrote:
>>>> From: Juergen Luethje
>>>> Sent: 28 jul 2004 y. 23:39
>>>> Igor Kachan wrote:
>>>>> CK Lester wrote:
>>>> How should B_ and C_ be defined, and how
>>>>  should the appropriate value
>>>> be assigned to B_ and C_?
>>>> Will you define a separate type for each sequence?
>>>>
>>>> <snip>
>>>
>>> Yes,  a separate type for each sequence.
>>>
>>> }}}
<eucode>
>>> integer B_
>>> type sequence_with_length_B()
>>> ...
>>> end type
>>>
>>> integer C_
>>> type sequence_with_length_C()
>>> ...
>>> end type
>>>
>>> integer D_
>>> type sequence_with_length_D()
>>> ...
>>> end type
>>> </eucode>
{{{

>>
>> And what is the advantage compared
>>  to conventional Euphoria programming
>> style, i.e. not using all those types,
>> but using 'length(A_A)',
>> 'length(A_B)' etc. directly?
>
> Really you have just 1 or 2 main sequences in your program.
> For example, ed.ex editor.
> So, you can enter these types and then
> use A_  or  B_  anywhere you want instead of, say,
> length(First_Very_Long_But_Very_Clear_Name_of_Main_Sequence_1)
> and
> length(Second_Very_Long_But_Very_Clear_Name_of_Main_Sequence_2).

Sorry, but this sounds somewhat theoretical to me. At least regarding to
my personal coding style, this will be rather unlikely. If a sequence in
my program is so important, that I feel necessary to give it a name
such as 'First_Very_Long_But_Very_Clear_Name_of_Main_Sequence_1', then I
probably will name the variable that holds its length
'Length_Of_First_Very_Long_But_Very_Clear_Name_of_Main_Sequence_1'
rather than just 'A_'.
Or, the other way round, if the variable 'A_' holds the length of the
sequence, then the sequence itself will prbably have a name such as 'A'
or 'sA'.

Anyway, I think your trick can be useful when there are only a few
sequences in the program, that often change their lengths, and the
lenths are often needed by the program. So it's not necessary always to
write
   A_ = length(First_Very_Long_But_Very_Clear_Name_of_Main_Sequence_1)

But if there are say 20 sequences, I think adding 20 types would add
considerable overhad to the program.

> But you could not use $-feature in the same manner,
> there is no the separate $-value at all.

Yes, it will only work for subscripting and slicing, but for these
purposes it will be more elegant than anything currently available in Eu
2.4, IMHO.

Regards,
   Juergen

19. Re: Euphoria 2.5

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 31, 2004
• 620 views

Hi Igor,

you wrote:

> Hi Juergen,
>
> ----------
>> From: Juergen Luethje
>> Sent: 29 jul 2004 y. 22:57

[snipped a lot in agreement]

> But old good EU [type ... end type], what a beautiful thing!
>
> I just remembered yours:
> "And what is the advantage compared to conventional Euphoria
> programming style, i.e. not using all those types ... "

Please don't get me wrong: I am not against the EU types.
But using a separate type for *each* sequence adds a lot of overhead, is
rather unusual, and also implies some risk for introducing bugs, when
another user tries to change the code, and isn't aware of this special
construction.

[snip]

Regards,
   Juergen

21. Euphoria 2.5

• Posted by Jason Gade <jaygade at yahoo.com> Nov 19, 2004
• 591 views
• Last edited Nov 20, 2004

I've been following this for some time and I wanted to share some thoughts...

What is RDS' customer base for 2.5?  I mean, who are the people paying
money for a license?

*Hobbyists with $80 to spend who want to make modifications run at full
speed and don't care if they can redistribute them.

*Hobbyists who want to bind or shroud their code.

*Business programmers who need to make modifications run at full speed and
can convince their customers to pay for the extra license.

*Business programmers who need to bind or shroud their code.

*Translator customers from the above categories who want to get rid of the
delay message.


Am I missing any?  I don't belong to any of these groups.

You can take this with a grain of salt because I have never registered
Euphoria.  Until Derek's contest I had never written more than 50 lines
or so of code with Euphoria.  My interest is mostly aesthetic.

I saw myself as more of a potential customer pre-2.5.  Now, except for my
features wishlist (which everyone seems to have), I get everything for
free with the PD version.  I could even write my own back-end or translate
Euphoria to yet another language or whatever.  I have no reason now to send
any money to RDS.

I think that RDS could make more money if they wrote a couple of books -- a
basic computer science text using Euphoria, and an intermediate/advanced
book on writing and implementing an interpreter using Euphoria as the case
study.

I would buy that book.

 j.

23. Re: Euphoria 2.5

• Posted by "Igor Kachan" <kinz at peterlink.ru> Aug 01, 2004
• 582 views

Hi, Ricardo.

You wrote:

----------
> From: Ricardo Forno <rforno at uyuyuy.com>
> To: EUforum at topica.com
> Subject: RE: Euphoria 2.5
> Sent: 31 jul 2004 y. 5:01
> 
> Hi, Igor.
> What are the non-documented side efects 
>  you are speaking of?
> Regards.

[snip]

> > And I am afraid that some time Rob will eliminate
> > the existing non-documented side effect as it already
> > was once with the translator  in "without type_check"
>  >  mode.

On Euphoria manual, [type ... end type] functions serve just 
for testing if the single parameter is of needed value.
But really you can use these functions for any an additional 
job as procedures on each assignment to typed variable too.
Maybe, this feature is not a 'side effect' in usual sense,
but it is not used in the official RDS programs, as far as I know,
is not described in the official RDS documentation and it seems
to be discovered by one of this list members. 
I myself know about this feature from the list and use it in
some my programs. This side effect is very useful, I think.

Really, why not use this thing if it does work well?

integer A
type sequense_with_length(sequence a)
  A=length(a)
    return 1
end type

There is no any user-defined tests of sequence a,
but this is the Euphoria [type...end type] construct,
which will prepare the new length(N) for you on any
new assignment to sequense_with_length N.

Is it a side effect or is it a very useful EU feature -
this is an issue of terms, I think.

Sure, It Is Not a Bug!       

Regards,
Igor Kachan
kinz at peterlink.ru

25. Euphoria 2.5

• Posted by "Hayden McKay" <hmck1 at dodo.com.au> Jan 29, 2004
• 624 views

--=======AVGMAIL-401856C941B3=======

------=_NextPart_000_004F_01C3E65C.DF2DB440

Now that we know that the new Euphoria interpretor will consist of a front end
and a back end, and more importantly, it will be mainly C. Euphoria will already
be one step closer to thing like thread and multiuser support.

After the new Euphoria 2.5 is released. I think we are going to see some really
good changes and possibilities In the later versions to come.

Keep up the good work RDS. Thnxs for making easy programing possible.

 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/04
------=_NextPart_000_004F_01C3E65C.DF2DB440
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1276" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Now that we know that the new Euphoria interpretor 
will&nbsp;consist of&nbsp;a front end and a back end, and more importantly, it 
will be mainly C. Euphoria&nbsp;will already be one step closer to thing 
like&nbsp;thread&nbsp;and multiuser support.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>After the new Euphoria&nbsp;2.5 is released. I 
think we are going to see some really good changes and possibilities In the 
later versions to come.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Keep up the good work RDS. Thnxs for making easy 
programing possible.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;<FONT face=Arial size=2></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><BR>---<BR>Outgoing mail is certified Virus 
Free.<BR>Checked by AVG anti-virus system (<A 
href="http://www.grisoft.com">http://www.grisoft.com</A>).<BR>Version: 6.0.572 /

------=_NextPart_000_004F_01C3E65C.DF2DB440--
--=======AVGMAIL-401856C941B3=======
Content-Type: text/plain; x-avg=cert; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Content-Description: "AVG certification"

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 28/01/04

--=======AVGMAIL-401856C941B3=======--

27. Re: Euphoria 2.5

• Posted by Robert Craig <rds at RapidEuphoria.com> Sep 07, 2004
• 613 views

Vincent wrote:
> I was just wondering what new features you implementing in version 2.5?

- a complete open source Euphoria interpreter written in Euphoria
  and 100% compatible with the official RDS interpreter (but slower)
- $ feature
- crash handler
- namespace improvement
- "-con" option in translator and binder will give you
  a Windows console mode .exe
- totally new binder
  - quick start-up - parsing has already been completed
  - fairly small .exe - you bind with the back-end only,
    not the full interpreter
  - shared front-end - no possibility of glitches or 
    differences with interpreter
  - better shrouding since the shrouded intermediate language,
    not the (shrouded) source is stored in the .exe
  - option to have full ex.err debug information when your user
    causes a crash (but your source is still not in the .exe)
- the usual assortment of bug fixes, documentation fixes,
  small translator code-gen improvements, trivial enhancements etc.

> And when you plan to release the alpha version of Euphoria 2.5?

I'm getting closer. I don't have a specific date in mind.
This project keeps getting more and more complicated. It takes
time to fully test all components on all platforms. 
Hopefully in a month or so I'll be very close, but I think it's
better for me to test things well and handle a small number of
bug reports, than put out something quick and sloppy and get flooded
with reports.

> Also I'm aware that you have written the initial interpreter in 70/30 hybrid
> code. 70% being Ansi C, and 30% being Euphoria, my question is how will that
> effect speed since the main interpreter is no longer 100% C coded like version
> 2.4
> and below? 

The front-end (scanning/parsing) is now written in Euphoria. 
It's translated by EtoC to C, compiled, and linked with the 
hand-coded back-end. The back-end is in carefully hand-coded C as before 
for full speed. So theoretically the front-end (only) is a bit
slower. But you won't notice it unless you have a very old machine,
and a very large program, and you watch the start-up time carefully.

> And for the Eu to C v2.5 translator that I believe you said would be
> written in 100% Euphoria code, how will that effect the compadability with
> various
> C/C++ compilers?

The fact that it's now written in Euphoria has no effect on 
compatibility with C compilers. It outputs the same C code
as before (except for a few bug fixes and performance improvements).
It takes slightly longer to run (an extra few seconds), 
but the subsequent C compiles still take a lot longer than the 
translation step.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

29. Re: Euphoria 2.5

• Posted by Robert Craig <rds at RapidEuphoria.com> Sep 07, 2004
• 610 views

William Heimbigner wrote:
> > The front-end (scanning/parsing) is now written in Euphoria.
> > It's translated by EtoC to C, compiled, and linked with the
> > hand-coded back-end. The back-end is in carefully hand-coded C as before
> > for full speed. So theoretically the front-end (only) is a bit
> > slower. But you won't notice it unless you have a very old machine,
> > and a very large program, and you watch the start-up time carefully.
> >
> 
> If it means it risks slowing it down, why did you rewrite part of it? It
> doesn't quite make sense. What is the AdVanTage of having it be 30%
> translated euphoria?

* It's the same front-end as the open source Eu in Eu 
  interpreter uses (avoids dual maintenance).

* The old C-coded front-end had lots of very ugly, complicated
  code to do with allocating/reallocating numerous data structures.
  The new front eliminates all that by using append() etc.

* I can test changes to the new front-end in interpreted mode,
  (subscript checking, uninitialized variable checking etc.), 
  not to mention profiling, interactive tracing etc.

* I like programming in Euphoria a lot more 
  than I like programming in C.

* the speed difference is tiny and will get tinier as
  machines get faster
  
Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

31. Re: Euphoria 2.5

• Posted by "Kat" <gertie at visionsix.com> Sep 07, 2004
• 598 views
• Last edited Sep 08, 2004

On 7 Sep 2004, at 11:38, William Heimbigner wrote:

<snip>

> > The front-end (scanning/parsing) is now written in Euphoria.
> > It's translated by EtoC to C, compiled, and linked with the
> > hand-coded back-end. The back-end is in carefully hand-coded C as before
> > for full speed. So theoretically the front-end (only) is a bit
> > slower. But you won't notice it unless you have a very old machine,
> > and a very large program, and you watch the start-up time carefully.
> >
> 
> If it means it risks slowing it down, why did you rewrite part of it? It
> doesn't quite make sense. What is the AdVanTage of having it be 30%
> translated euphoria?

Because it MIGHT allow some of us to make improvements in the human-
written side, for adding things like case, goto, repeat-until, inline, string 
execution, namespacing, local includes (Bach's import), and threading (or 
maybe something else like Al Getz's windows server), associated lists (like 
Jiri's, or the hash() in Bach), or just whatever other function Eu lacks that
you
need! If a change i make is written in Eu, and a change you make is written 
in Eu, merging the changes is much easier. The output code is still 
compatable with the execution unit.

> <snip snip>
> William Heimbigner - who is very happy as he has just started 9th grade
> today!
> icxcnika at hotpop.com

Congrats.

Kat,
graduated 9th back in ancient history.

33. Re: Euphoria 2.5

• Posted by Terry Constant <EUforum at terryconstant.com> Sep 08, 2004
• 613 views

Craig wrote:
* I like programming in Euphoria a lot more 
  than I like programming in C.

Of course. That is a prime reason I use Euphoria and likely 
why many users do. Keep on making out lives easier/better with Euphoria!
I assume the front-end will now be easier to maintain and improve,
which far out weighs the insignificant slower time.

Terry Constant