OpenEuphoria

1. Euphoria's strengths

• Posted by jaygade Jan 08, 2015
• 1810 views

To me, Euphoria's strengths are as follows:

• Clear and readable syntax
• Generic lists
• Typing that is as dynamic or as static or as strong or as weak as the developer wants

These are the strengths which Euphoria should continue to capitalize on. Most other "new" features are a distraction.

That's not to say that new concepts or ideas aren't welcome, but rather that they really have to prove their worth beyond a reasonable doubt before modifying the Euphoria spec to include them.

In my humble opinion.

3. Re: Euphoria's strengths

• Posted by Shian_Lee Jan 08, 2015
• 1821 views

'New' doesn't mean 'Better'.

In most cases, from a very wide point of view, 'New' is the worst.

Some new gifts, such as the Penicillin, meant life for millions of people.

Other new inventions, such as many war machines and supercomputers - will soon or later fall into the hands of a world's dictatorship. means death for billions of people.

If my life had to depend on USB or RS-232 communication, I could only choose RS-232, because it's my life.

I like Euphoria because it's (still) simple.

5. Re: Euphoria's strengths

• Posted by DerekParnell (admin) Jan 08, 2015
• 1810 views

Evidence, please?

7. Re: Euphoria's strengths

• Posted by useless_ Jan 10, 2015
• 1700 views
• Last edited Jan 11, 2015

Very little of what i believe makes a good programming language has been added to Euphoria. And while i support what DCuny has said (and he's been in this forum longer than i have), i'll point out that for the most part if i support it, it's not going to be part of Euphoria.

I am currently writing new code which i'd much prefer to write in Eu, but cannot. The language i chose has access to the variable table so i can see if a var is there before i use it. And i can search the var table with wildcards, during runtime. I can tell if a procedure is available, and which "include" file has it. I can tell if an "include" file is loaded, and i can load or unload it during runtime, with or without init code running at load or unload time. I can also build a string of code during runtime and execute it. Or i can load and execute a file of code during runtime. While the language has windows gui support for the coder, i have not used it in depth, but only for interaction with the application in text-only. The windows have programmable popups, programmable during runtime. And all this runs interpreted, and loads much faster than Eu. It's not Lua.

Those things i have lost all hope of ever seeing in Euphoria. Most of them i have asked for for years. I miss Eu's sequences and speed, but at least i have functionality in the other language.

useless

9. Re: Euphoria's strengths

• Posted by Ekhnat0n Jan 11, 2015
• 1617 views

@GreenEuphorian:
I second your request but I fear the language 'useless' is using
will be useless to us as it might well be:
very hard to learn
very obscure to decypher
almost unreadable
very demanding on type-controlling variables etc
in one word USELESS and
far less USER-FRIENDLY than Euphoria.

11. Re: Euphoria's strengths

• Posted by dcuny Jan 11, 2015
• 1595 views

Look at the conversation on try/catch.

While I appreciate the forward direction this conversation has taken, these sorts of responses had me ready quit Euphoria entirely.

- David

13. Re: Euphoria's strengths

• Posted by useless_ Jan 11, 2015
• 1575 views

Ekhnaton, you are attacking the language without even knowing what it is. In fact, regarding types, you can assign a string or an integer to any variable, or you can assign $null. I agree this isn't necessarily a good thing. The reserved words are very BASIC-like, as is Euphoria, but unlike Euphoria, you can override them and stop the built-in from executing if you like, because user code executes before the built-ins.

GreenEuphorian, i won't say the language's name because people get banned on this forum for advertising.

useless, but not because i want to be.

15. Re: Euphoria's strengths

• Posted by jimcbrown (admin) Jan 11, 2015
• 1590 views

I feel that dcuny himself is best positioned to implement his own ideas the manner most confirming to his original vision.

That said, we've already implemented quite a few of his ideas, such as dot4 and desequencing.

I'd argue that we've implemented even more of his ideas in spirit (such emulated PBR through eumem), though it's clear that he doesn't always agree.

We have ... however, some of his ideas are harder to implement than others.

Agreed, talking about a topic is good but nothing beats coming up with a prototype implementation or a preprocessor to demo an idea out.

dcuny, correct me if I'm wrong, but I don't recall this being one of yours.

That said, it's not a bad thing to have. I certainly wouldn't complain if someone came up with a patch to implement this in Euphoria.

It's just plain hard to do.

17. Re: Euphoria's strengths

• Posted by Ekhnat0n Jan 11, 2015
• 1725 views

@useless:

Don mention any properties of any language whatsoever
comparing it with Euphoria
without mentioning that language.

you ought to be banned

for NOT telling the language
as it's cheap stating things without offering opportunity
to verify your claims.

19. Re: Euphoria's strengths

• Posted by dcuny Jan 11, 2015
• 1522 views

Let me clarify: I'm certainly not threatening to leave because my ideas haven't been implemented.

There have been many changes made to Euphoriasuch as:

{a, b, c} = foo() 

This is a huge.

It's easy to suggest things. It's quite another thing to make it happen, and happen well. And people have been doing it - I don't mean to imply otherwise.

Heck, simply maintaining Euphoria is worthy of respect.

And while I disagree with people, that doesn't mean that I don't respect their ideas.

My ideas may be completely wrong, and there may be better ways of doing things. The only way to get to that point is through discussion, and forums aren't always the ideal place for these things to happen.

My complaint is with the tone of some of the conversation. We can be passionate Euphoria and still maintain that respect.

- David

21. Re: Euphoria's strengths

• Posted by petelomax Jan 11, 2015
• 1534 views
• Last edited Jan 12, 2015

Really? Of course I'm looking at this from a purely Phix perspective, and apart from nested block scopes, I'd say this was reasonably trivial.
Unless you were expecting it to magic previously-undeclared variables out of thin air or suchlike.
If one of those pesky fatal errors can print "i = 5" to an ex.err then the runtime can clearly map values/storage addresses and variables/names.

This is how it might go in Phix, not that I'm convinced it would necessarily prove to be particularly useful:

A var_id(), like routine_id(), is a simple integer index to the symbol table.

Only two fairly simple routines can actually use a variable id, set_var(id, x) and x = get_var(id).

NB The following two restrictions may cause arguments, but I'd rather limit things, even drastically, than have mildly incorrect code potentially cause any and all manner of weirdness...

Since it is not permitted to access a block scoped variable outside that scope, but the scope of a variable and a corresponding variable id may differ, variable ids may not be obtained for variables with a limited (block level) scope. In the example below var_id("i") and var_id("j") are fine but var_id("k") and var_id("l") are not, because of where i, j, k, and l are defined. Obviously, you are free to store a variable_id, when you can get one, in a block scoped variable.

While global and file-level variables have precisely one location, and variable ids for them can be used anywhere, parameters and locals can have zero or more locations, and variable ids for them can only be used in the same routine where they are declared. Oh, and obviously because of standard scope rules, that is also the only place you can obtain a variable id for a local in the first place. Both set_var and get_var check the currently active frame is correct, and hence a viable storage location exists, before proceeding (when dealing with a local variable). In the example code below there is absolutely no possible valid storage location to store the 7, as there is no active frame for f, which is where j lives.

The following code illustrates some permitted and invalid uses:

procedure p(integer id) 
  set_var(id,4) 
end procedure 
 
integer i 
function f() 
integer j 
integer idi = var_id("i") 
integer idj = var_id("j") 
  set_var(idi,5)    -- fine 
  p(idi)            -- fine 
  set_var(idj,6)    -- fine 
  p(idj)            -- runtime error 
  if c then 
    integer k 
    integer idk = var_id("k") -- error (k not top-level) 
  end if 
  return idj        -- dubious 
end function 
set_var(f(),7)      -- runtime error 
if c then 
  integer l 
  integer idl = var_id("l") -- error (l not top-level) 
end if 

Technically it would be quite possible to make p(idj) find and trash the callee's j, but potentially risky, would have to would have to fail if g() called it anyway, unless f() called g(), and even then it could be an unrelated call we're clobbering...

Lastly, set_var() must also invoke the appropriate typecheck, if any.

I would be quite happy to make set_var() yield true/false rather than crash on invalid var_id. I'd want valid_id() over get_var() returning {SUCCESS,x} but I won't argue.

Did I miss anything?

Pete
PS Of course that was the theory, practice may be a different matter altogether.

23. Re: Euphoria's strengths

• Posted by useless_ Jan 12, 2015
• 1487 views

One of the hoops i jump thru in Euphoria, for variables, is to use an associated list, vars.name and vars.value, and setvar("name",value) and getvar("name"). Then find() and match() etc work normally on the lists, i can search for a value or a name, and use wildcards. If the varname isn't there, i can make it, this helps a lot with inheritance. This is actually an old workaround, from October 2003. It can get cumbersome, and the first run of a program tells me where i used the transparent normal syntax of Euphoria and not the special vars list syntax. And i know i am taking a speed hit, which shouldn't happen with native support in the core. Same problem with memory use: once used it isn't ever returned to the OS. But this is an example of a feature users could load in an include file if they don't mind the syntax being different than normal Eu code.

I tried to write a interface using new reserved keywords as a scripting language running on Euphoria, it didn't work. I couldn't recieve parameters and pass them to Euphoria properly. This would have been a workaround for not having string execution in the core. Spawning new processes doesn't work either, because you cannot use the existing environment, you cannot make an include file to instanciate the variables if you don't know the varnames to write into the include file for the new instance. Having access to the varlist in Euphoria might fix the lack of string execution, if you can accept the long time to launch a new Eu app, just to run one string. But if it's run repeatedly, the startup time is a hit only once. Keeping the two environments sync'd may be an issue.

Tasks was a great workaround for event driven code. I wrote an event driven ircd and httpd in the other language, but tasks seem to work equally well for that sorta thing, if differently, in Euphoria. Tasks may be a good workaround for timers in the other language, i have not tried, i have been away from Eu for some time, partly because my code for task message passing was rejected. I quit working on that in Oct 2013, because someone else was developing it.

useless

25. Re: Euphoria's strengths

• Posted by mattlewis (admin) Jan 12, 2015
• 1465 views

In the interpreter, it's pretty trivial. Basically a few hooks and some understanding of the data structure (which gets a lot easier with memstructs ). This has been done already for 4.1.

I also remember writing that into a version of the...umm....pre-open source version of the source I bought off of Rob (that used a similar var_id scheme to what you proposed, IIRC). So, 2.5, maybe? And some access is there already in 4.1, at least to interpreted programs.

It's more difficult to do that with translated programs. And hasn't been implemented yet. We'd need to create a symbol table similar to what we have for routine ids. Possibly multiple, in order to allow access to non-file-level vars.

Matt

27. Re: Euphoria's strengths

• Posted by jimcbrown (admin) Jan 12, 2015
• 1455 views

I feel we should point out that a lot of what debug.e does doesn't work on translated (at least not yet).

29. Re: Euphoria's strengths

• Posted by jimcbrown (admin) Jan 12, 2015
• 1457 views

Why? (Just curious.)

31. Re: Euphoria's strengths

• Posted by useless_ Jan 12, 2015
• 1432 views

i would be very happy to see code appear as interpreted-only, just to get it. I have not bound or compiled Eu in over a decade. Of course, i may want to again some day, and i understand why the interpreted and compiled (and bound?) should act the same. Ummm, am i correct that if a feature runs only interpreted, it runs when bound too?

I seem to recall my patch to news.e to speed it up also didn't work if compiled. That was a tasks.e issue.

useless

33. Re: Euphoria's strengths

• Posted by jimcbrown (admin) Jan 12, 2015
• 1442 views

Ok, then that's much easier.

Today, debug.e already supports simple lookup of variable names via the symbol_lookup() function and friends. Wildcards and such aren't supported, however.

debug.e also already supports checking if a variable is init'd or not, via the is_novalue() function.

I don't see them being linked. This is a desired feature, but adding it is just plain hard. If someone handed us a patch with this already implemented (even interpreter only), we'd almost certainly take it and add it. However, the only person who has done this successfully that I know of is mattlewis, and his version is out of date (being based on a 2.x version of Euphoria) and hard to upgrade to the latest (due to it being based on a complete rewrite of the interpreter originally by dcuny).

Then it's possible that what you want is already available today, in debug.e ...

No... binding does lose some information that an unbound program would have. Most features will work regardless, but getting all the metadata in a bound program is more work.

35. Re: Euphoria's strengths

• Posted by petelomax Jan 12, 2015
• 1393 views

Erm, gut feeling, mainly, I suppose. If the compiler is prohibiting "i:=5" then letting the programmer defeat the compiler using var_id() sounds like an accident waiting to happen.
Certainly, in Phix, the end for is optimised to use the register version (if not reused) and clobber the memory copy without even checking it, because right now, it can.
Maybe/Probably the presence of a get_id()/set_var() in the loop body would be enough to ensure the register has been recycled before it gets to the end for.

There is also another matter/warning that I completely missed: type inference.
If the compiler deduces that an atom (eg loop control var, but others too) is, say, an integer, but set_var() sets it to a float, it'll go belly up for sure.
There is some constant/range propagation that I nicked from Eu, which might break, and Phix also has string/sequence and inferred udts to worry about.

Pete