OpenEuphoria

1. Data structures in the next release

• Posted by GreenEuphorian Jul 26, 2014
• 2439 views

Hi

I would like to know if data structures are still a priority for the next release, and when this is likely going to happen.

Thanks

GreenEuphorian

3. Re: Data structures in the next release

• Posted by andi49 Jul 26, 2014
• 2373 views

From my point of view. Euphoria is dead and outdated. You better do not await something new.

So structs are nothing to wait for.

It's a toy language, you can play with it and then go on to something real.

I still like it (becouse i'am just playing) but i do not await real progress.

It's nice for text processing but does not offer something you can't do in any other language. Its just easy to learn.

So i think data structures are never likely to be happen... (becouse there are not easy to learn and do not fit into the simple Euphoria typesystem).

Just my point of view
Andreas

5. Re: Data structures in the next release

• Posted by SDPringle Jul 28, 2014
• 2390 views

I have come to the idea that native Euphoria structs are possible already:

enum  
  TM_SEC, 
  TM_MIN, 
  TM_HOUR 

We ought to provide library routines for this kind of thing:

sequence s = struct_assign(TM_HOUR, 5, TM_MIN, 30, TM_SEC, 0) -- sets to 5:30:00 
-- s is {0,30,5} 
s[TM_SEC] is 0.  s[TM_HOUR] is 5. 
 
s[TM_MIN] = 45 
-- s is {0,45,5} 

I have already written these two routines. If anyone would like them, I wrote these some time ago, and they are tight and tested and they don't require 4.1 (probably would work on 3.1)

I know C style structs are much safer than this. It seems to me, if you could bind the indices to the enumerated list somehow so it is only valid in sequences that contain some special syntax you would get the big type safe advantage of C without all of the c types. But then you might end up with something that is so much like C and you would lose the flexibility of EUPHORIA.

I do not use EUPHORIA except for developing it and for writing short little scripts to do some kind of text processing task. For myself the problem is extrinsic to EUPHORIA: A new cool library comes out for AI and it will be written in C++ or Python or Java. Then you have to write a wrapper for it in order to start using it. Because EUPHORIA is consistently pass by value (virtually) the syntax will be different. So, the wrapper ought to be documented.

If someone writes a wrapper they often neglect the documentation and if it is a thick wrapper the lack of documentation makes the wrapper useless. Sometimes the documentation is incomplete, or wrong. This is only made worse by those who change things but are not prepared to look at all of the pages of the documentation and see what needs to be changed and fix that.

In the end, it is analogous to a natural language. It is useful if people speak it. People speak it if it is useful. Lately I have had no time for Euphoria development. Other activities in my life have grown and there is only so much time in a week.

S Pringle

7. Re: Data structures in the next release

• Posted by jimcbrown (admin) Jul 28, 2014
• 2128 views

That's a good point. memstructs is for interfacing with C (when you have no choice but to use pointers).

Conceded.

I agree with SDPringle here, we more-or-less already have them: http://openeuphoria.org/forum/m/124818.wc

It'd be nice to see struct_assign() in the stdlib though, and maybe even some syntax sugar for it.

Agreed, Euphoria is slightly older actually (it started in the mid 80s, Linux kernel was 1991 or 1992 iirc).

The big difference IMVHO is that Euphoria wasn't open source until just a few years ago.

And I can assure you that more progress is in the works.

Phix had it first: http://openeuphoria.org/forum/120729.wc#120729 (I consider Phix part of the Euphoria family of languages...)

There's also an OpenEuphoria version that's in-progress (but highly experimental)...

Ditto.

Conceded.

But being easy to learn is a huge benefit regardless. Being easy to use would be an additional huge benefit.

Why not?

Even if we had huge differences (I'm thinking Java vs Ocaml/Effiel/Erlang/C-- here), I'm not sure it'd make much difference in terms of usage. Ray Smith had it down IMVHO - the biggest, most popular languages tend to have the biggest commercial backing. Short of having all of that, we just simply can't compete in terms of marketing, advertising, etc.

The result isn't the same, because assembler is hard to learn and hard to use (relatively speaking), and it's not portable. There's no single assembler language, but a bunch of them (roughly one per cpu architecture), and you more or less have to relearn everything from scratch when you move to another arch.

If you really wanted to, I suspect you could catch up really quickly. A lot of the work in adding new features to Euphoria can be written in Euphoria itself. I've seen your past work in the language and rated it highly.

I've used tinewg and I think you sell yourself short here. I find it a great product.

Agreed. But, well, real-life and all that ... what's a person to do?

You mean the eubins? Getting those back up is definitely a priority.

You mean eubins for all of these branches? 64bit support has been up there for a while. I think Matt has put up binaries for his branches, like memstructs, from time to time as well.

Or do you mean info on the download pages explaining what's happening with each update (i.e. what's changed) ? I'm not sure it makes sense to have all that information in the download page however. That's available from the hg logs (which you can browse online) and from the release notes (also available online).

9. Re: Data structures in the next release

• Posted by Lone_EverGreen_Ranger Jul 30, 2014
• 1978 views

I would hope that data structures will make it into the next release. They would come in handy.

11. Re: Data structures in the next release

• Posted by jimcbrown (admin) Jul 31, 2014
• 1869 views

Wait... Aren't we already doing that?

Then what else?

The changelog will not change too much between hg commits. I'm not sure of the utility of this.

If it's per release ... then we are already doing this.

This is not possible. There have been no new releases in the past 6 months.

I think including the full hg logs, or even the full changelog (the release notes) on the downloads page is not practical. They'd just be too large and take up too much space.

A short summary would probably work though. Since the downloads page is a wiki page editable by any logged in user, this means that any person with the spare time can go ahead and do this.

13. Re: Data structures in the next release

• Posted by jimcbrown (admin) Aug 01, 2014
• 1910 views

4.0.5 is the most recent 4.0.x release, so I can not point you to a newer release.

Some newer eubins are available however, e.g. http://openeuphoria.org/eubins/windows/4.0.5/eubins-watcom-20131210-e79275ac5d37.zip from http://openeuphoria.org/eubins/windows/4.0.5/

(Based on the hg log, that's the newest eubin required. Any additional changes to the 4.0 branch since then have occured either in documentation, tests, or the stdlib, and do not require any recompiling to be used with the latest eubin.)

There are no official releases for the structs branch yet. However, some precompiled eubins are available here:

http://openeuphoria.org/eubins/struct/