OpenEuphoria

1. ver4 keyword Conflict

• Posted by BRyan Oct 03, 2011
• 1651 views

keyword: ' tan ' is a built-in math function

tan is also a color name used by xpm files, and other programs

How come tan is built-in and not isolated to the Math library ?

3. Re: ver4 keyword Conflict

• Posted by BRyan Oct 03, 2011
• 1660 views

Putting it another way

The 4.0 scanner is looking for a '( ' after ' tan ' and can not

tell the difference of the constant ' tan ' from the function ' tan '

5. Re: ver4 keyword Conflict

• Posted by jeremy (admin) Oct 03, 2011
• 1635 views

For example:

include abc.e as abc 
 
override function tan(atom a) 
  return a * 100.0 
end function 
 
? abc:tan -- tan constant found in abc.e 
? tan(10) -- your tan function 
? eu:tan(20) -- euphoria's built in tan function 

7. Re: ver4 keyword Conflict

• Posted by mattlewis (admin) Oct 03, 2011
• 1617 views

Anything implemented in euphoria or via machine_func or machine_proc goes into the standard library. tan has always been a built-in. Likewise, puts is still built-in, and not located in std/io.e. I don't foresee tan (or, e.g., sin, sqrt) going anywhere.

Matt

9. Re: ver4 keyword Conflict

• Posted by BRyan Oct 03, 2011
• 1613 views

Jim:

Most code written for 3.11 or earlier is not compatible with ver 4 because of

DOS code,DOS interrupts, conflicts of keywords, etc.

Also compatible problems with Linux code

11. Re: ver4 keyword Conflict

• Posted by jeremy (admin) Oct 03, 2011
• 1603 views

I disagree. Almost all of my programs from 3.x ran just fine under 4.x w/no change. I did use a keyword in one of my libraries and had to make a change there.

Jeremy

13. Re: ver4 keyword Conflict

• Posted by jimcbrown (admin) Oct 03, 2011
• 1611 views

4.0 was going to break code from earlier versions because of the scope of the changes. Agreement was reached that this would be the very last time that breaking changes should be required though. (At issue was the way namespaces were done.)

(A caveat - some changes planned for 5.0, like object oriented support, might eventually require breaking changes as well. Still, lets hope that lessons learned in the move from 3.11 to 4.0 will be remembered and applied when the time comes.)

Can't argue with that.

This is inevitable. A preprocessor is included with 4.0 to rewrite code to fix the conflicts, so this should only be a minor nuisance, not a major roadblock.

I was not aware of this. Examples?

15. Re: ver4 keyword Conflict

• Posted by BRyan Oct 03, 2011
• 1587 views

[ problems with Linux code ]

I was not aware of this. Examples?

Jim:

What about curses ?

17. Re: ver4 keyword Conflict

• Posted by jimcbrown (admin) Oct 03, 2011
• 1635 views

Even when we had it, I wasn't happy with the way it was implemented. It was basically linked in to make it easier to implement position() and get_mouse() et al. and nothing more. None of the underlying ncurses stuff was exposed throught he langauge, you couldn't use it at all. (Well, you could do it via open_dll("") on Linux/GNU but imvho this isn't different at all from just open_dll("libncurses.so.5") - which should still work with 4.0.)

ncurses has a separate set of functions for wide character (e.g. unicode) support that weren't compatible with the older set of functions (that is, you weren't allowed to mix and match calls from the two sets, you had to pick one or the other) and since Euphoria only used the non unicode set, it wasn't possible to do unicode/UTF-8 with Euphoria and urxvt.

This works very nicely with 4.0, however. (It should work fine with 3.0 as well, since that's when ncurses was removed.)

Is there anything else besides ncurses and get_mouse()/gpm ?

19. Re: ver4 keyword Conflict

• Posted by petelomax Oct 03, 2011
• 1602 views

I'm not sure what the fuss is about. It just means

?tan(0.5) 

would have to become

include std/maths.e 
?tan(0.5) 

Is that really such a deal breaker?

Pete

21. Re: ver4 keyword Conflict

• Posted by jimcbrown (admin) Oct 03, 2011
• 1573 views

?tan(0.5) 

include std/maths.e 
?tan(0.5) 

Less so for 4.0

In the past, you might have had issues if you wanted to use the name tan for something else. I think 4.0's namespacing handles this quite nicely though, and as Matt points out you can declare a constant with the name tan and use it as a color too - at least in 4.0.

23. Re: ver4 keyword Conflict

• Posted by mattlewis (admin) Oct 03, 2011
• 1576 views

Well, simply with respect to speed, I wouldn't worry about the I/O performance, since the actual I or O is typically going to dwarf just about anything we do. Stuff like tan, however, is quite likely to be speed critical for someone doing lots of number crunching.

This would be especially important to someone working on, say, a physics library.

Matt

25. Re: ver4 keyword Conflict

• Posted by BRyan Oct 03, 2011
• 1537 views

Matt:

If someone is smart enough to be working on a physics library they would use another

language like FORTRAN in a DLL or SO.

They would not depend on the Euphoria to do the High speed complex calculations.

27. Re: ver4 keyword Conflict

• Posted by jeremy (admin) Oct 03, 2011
• 1529 views

Um, what? Have you seen any games written in Euphoria? What about in Fortran? Besides, it was just an example. I doubt a Euphoria programmer wants to write a physics engine in Fortran just to write his/her game in Euphoria.

For another example, I have a program that I am working on which takes a route defined in a GPX file and estimates given your performance metrix how long it will take you to traverse the route, bicycling or hiking. This is very calculation dependent. I can perform these calculations faster in Euphoria than any other language I use on a regular basis except for C, it's a bit faster. That's just another example. I'm sure there are hundreds of examples. For mine, it needs to be as fast as humanly possible because I wish it to execute in web requests and some GPX files will be 100,000 lat/lon points. I have to be able to compute the distance, bearing, elevation change, grade and then apply performance metrix from other sources and then compute new lat/lon points based off each of those metrix. Euphoria gives me that ability right now. No way I want to develop a web application in Fortran. Nor do I want to write all my formulas in Fortran, creating a DLL/SO, then wrap it in Euphoria. I use Euphoria because it's fast, at math alike.

Jeremy

29. Re: ver4 keyword Conflict

• Posted by BRyan Oct 03, 2011
• 1530 views

Jeremy:

You did understand what I said was to use math critical calculations in

another language like FORTRAN in a DLL and CALL them from Euphoria.

31. Re: ver4 keyword Conflict

• Posted by BRyan Oct 03, 2011
• 1534 views

MATT:

Download from the archive the file "Axiom Editor" and run it on 4.x.

You also need win32lib dated Jun 17/08 from the archive

Run the editor and you will see the conflict tan constant has with tan function.

This is just an example to show you that namespace

can not solve all conflicts only editing can solve them.

If tan was in a math library then namespace would be fine.

33. Re: ver4 keyword Conflict

• Posted by mattlewis (admin) Oct 03, 2011
• 1537 views

Yes, I understand what you're saying, and I agree that some pre-4.0 code will require some editing. You've found one example. The problem is easy to solve, and some older code will need to be updated.

Matt

35. Re: ver4 keyword Conflict

• Posted by jimcbrown (admin) Oct 04, 2011
• 1493 views

Err, use http://openeuphoria.org/pastey/95.wc

37. Re: ver4 keyword Conflict

• Posted by Vinoba Oct 04, 2011
• 1530 views

There is an extensive set of routines and libraries available in Cern library. It seems they are free to use and there are wrappers and several GUIs too. They use these routines to define how to accelerate particles so as to annihilate us all in the shortest possible time. It would be worth your while to look at these and I am sure you all (at least at the Euphoria developer level) would be able to use them in your accelerated, high speed, self-destructive physics calculations!
No offense intended.
http://cernlib.web.cern.ch/cernlib/

39. Re: ver4 keyword Conflict

• Posted by jimcbrown (admin) Oct 04, 2011
• 1497 views

No argument there. Although I'm not sure this case is the best example. The keyword conflict exists in Euphoria 2.3 (I think that's when namespaces were first introduced) so I'm assuming the issue here is that someone is trying to port pre-2.3/pre-namespace code over, in which case some editing is required. If this code had been written for 2.3 (or later), then no editing would have been required. (At least, not for this case.)

I had assumed that the argument was that editing the file to make use of namespaces was not enough, but that it was also necessary to change the name of the constant from tan to some other name (like Tan or TAN or thecolourtan) because edits to make use of namespaces were, by themselves, not enough to resolve the problem.

Perhaps this thread should have been named "Y2K1 ver2.3 keyword Conflict"