OpenEuphoria

2. Re: SLASH should not be a builtin

• Posted by DerekParnell (admin) Sep 18, 2008
• 1540 views

The documentation is wrong. SLASH is not a built in symbol.

See around line 126 in filesys.e ...

ifdef UNIX then 
	public constant SLASH='/' 
	public constant SLASHES = "/" 
	public constant CRLF = "\n" 
	public constant PATHSEP = ':' 
elsedef 
	public constant SLASH='\\' 
	public constant SLASHES = ":\\/" 
	public constant CRLF = "\r\n" 
	public constant PATHSEP = ';' 
end ifdef 

4. Re: SLASH should not be a builtin

• Posted by jeremy (admin) Sep 18, 2008
• 1506 views

I'm not understanding the problem with them, can you say why it's a problem for Euphoria to define them for you?

Jeremy

6. Re: SLASH should not be a builtin

• Posted by DerekParnell (admin) Sep 19, 2008
• 1490 views

I think I can come up with some other contenders ...

Good idea. If its not going to be a problem I'll get it done.

8. Re: SLASH should not be a builtin or constant

• Posted by DerekParnell (admin) Sep 19, 2008
• 1509 views

Yes they do. User of the library need to know that a third-party library hasn't altered these from the usual values.

If you need to use a different value for your application, then it would be best to define an application specific symbol.

10. Re: SLASH should not be a builtin or constant

• Posted by mattlewis (admin) Sep 19, 2008
• 1490 views

I don't think that there are any global symbols in the standard library in 4.0. I believe that they're all public.

I guess the hint is too subtle for me. What would platform_override() do?

If the 3rd party code is supposed to use application defined values, then it should have an API for doing so. I don't think you should try to pull the rug out from under a library by redefining things like the standard library, unless you're willing to go into the library and edit the code if anything breaks.

The point of the standard library is that it is standard, so if you decide to use it, you know what to expect.

Matt

12. Re: SLASH should not be a builtin or constant

• Posted by mattlewis (admin) Sep 19, 2008
• 1454 views

No, it's more than semantics, since it's a different scope. Basically, it's a more limited scope than global. So only files that include the file where it is defined (or that take advantage of public include) will be able to use it. It's not terribly relevant to the issue we're talking about here, but it is an important distinction.

Ah, ok. We have this using:

without define LINUX 
with define OSX 

Actually, what I'm suggesting is a more general principle, which is that you risk breaking 3rd party code if you alter things that it depends upon. It might use some of those constants in ways other than the obvious.

I think that there are some things where this is worthwhile, but I disagree that the constants were currently discussing fall into that category. You're free to use any definition you like, but I think that for these, there are good reasons for them to be the values that they are, and for the coder to be able to make assumptions about them.

If any piece of code could change the value of SLASH, for example, then any user of that variable would have to test it to make sure it was the value that he needed. Which either renders it pretty useless, or makes combining 3rd party libraries needlessly dangerous, and perhaps impossible. If you want to use a non-standard value, don't use the standard library.

Yep, I'm sure there will be some, as there always are. It's impossible to please everyone, but I think the standard library has really grown in some very important and beneficial ways, and I think it will be more useful to more people than it was before.

Matt

14. Re: SLASH should not be a builtin or constant

• Posted by bernie Sep 19, 2008
• 1463 views

Another problem is what would happen if a user may wish to
use more than one 3rd party library then what would you do ?

without define LINUX 
with define OSX 

16. Re: SLASH should not be a builtin or constant

• Posted by DerekParnell (admin) Sep 19, 2008
• 1451 views

Damn! What did we miss?

18. Re: std libs (Was: SLASH should not be a builtin or constant)

• Posted by scooby Sep 19, 2008
• 1460 views

error.e! :) - fatal_error(), abort_error(), error(), errorf(), set_error_routine(), get_error_routine() - pseudo exception handling throw, catch, drop, fetch, trap...

structs.e - eu is in dire need of a better C/ interface. This would greatly increase the productivity and more importantly, standardization of porting external API's. Whether the average programmer will be dealing with C interfaces directly is not important. What is, is that there is a wealth of API's available in other languages, which eu programmers need to be able to easily access. Someone needs be able to port them and optimally, we don't want to have to redocument everything either, which is the biggest chore. So we need to be able to create ports which represent the original API as accurately as possible, excusing differences between language syntax.

Chris Bensler Foo - The Programmers 'F' word

20. Re: std libs (Was: SLASH should not be a builtin or constant)

• Posted by mattlewis (admin) Sep 19, 2008
• 1502 views

We have crash()which is, or will be, a built-in routine. What is the difference between fatal_error() abort_error(), error() and errorf()?

We have crash_routine(), which seems to be the same as set_error_routine(). We don't have the get side of that. Would that really be useful?

What would you imagine the exception handling [in a library] doing? It seems to me that to be useful, we'd need to have exception handling built into the language itself.

Yeah, this would be a really good thinga standard structure library. There are a few out there. My favorite has always been the one that David Cuny developed for Win32Lib. Let the fighting begin!

Anything that uses a C-like interface is easy to interface with, and we've already got the tools for doing so. Languages like C are more difficult, and are not a problem that we're going to solve.

Matt

22. Re: std libs (Was: SLASH should not be a builtin or constant)

• Posted by scooby Sep 19, 2008
• 1458 views

All of the mentioned routines accept a string msg and are descriptive. fatal_error(msg) will call crash_message(msg) before crashing abort_error(code,msg) will echo msg to stderr, prompt user for key press then abort gracefully with code error(msg,args) will call the user-defined error routine errorf(msg,args) calls error() passing sprintf(msg,args) as msg, I should have omitted this, it has issues

get and set allow for multiple error routines to be stacked and called recursively. So one lib can safely redefine the error() function and have the new handler call the old error handler that may have been set by another lib, or choose to override. A stack would be better.

I should have described it as error trapping instead. There is no way for a library implementation to offer the same level of automation and cleanliness as builtin syntax. There is no elegant way to unwind the stack.

Here is a short description from the comments of the lib: These routines make it possible to throw an error from one routine, back through the call stack,

where they can be trapped and handled automatically, using the defined error handler, or they can be caught and handled on demand at the program level.

The lib can be configured so that thrown errors act immediately, like any other error. It can also be configured so that if multiple errors are thrown, they will trigger a cascade. Or multiple errors can be put on the pending stack, to be handled later at the callers discretion.

Short example: allow_error_trapping(TRUE) not scope specific :( allow_pending_errors(TRUE) "" ""

global constant ERROR_FSEEK = define_error(NULL) use the deault error handler ( error() ) global procedure fseek(file_num fn, file_pos pos) if machine_func(M_SEEK, {fn, pos}) then throw_error(ERROR_FSEEK,"seek error") stack the error handler until it is trapped end if end procedure

Called from: fseek(fn,pos)

Called from: etc... if drop_error(ERROR_FSEEK) then - don't care, discard close(fn) we're done end if trap_error(NULL) catch any remaining errors

Chris Bensler