Stack trace on fault

[rpcope1]

Greg,

I had a couple of weird errors playing around with Duck recently, and program will throw out stuff like "Error 1", when I screw something up. It may be a little early in development to consider, but would it be reasonable to implement the facilities to deliver a stack trace at some point? I'd be willing to help or (with some care studying and guidance) take charge if need be to get that in. Just a thought, hope your Thanksgiving break is going well.

Robert

[sh19910711]

good :)

[gregtour]

Hey there Robert,

This would be a great thing to implement. Currently, the runtime environment keeps track of a single error code passed back from interpreter routines, which were erroneously being cast to booleans, resulting in the infamous "Error 1" message. Now after the latest merge, there are three or four different error codes that can be returned, depending on errors in assignment, variable dereferencing, or trying to make a function call on another data type. It would be possible and relatively easy to output the function call stack returning from an error, and I will probably implement this in the next week.

I know the example you were referring to was with a library function of the same name as the library or other entry of the same name which would cause an error. The reason for this is that the statement "import " creates tag references for all of 's members in the global namespace. So rand would be replaced with rand.rand() but all of the other library routines would still exist, now public. I'm not sure if this is intentional. It may make more sense simply to require common libraries to be linked, or in the case of dynamic-linking, to be loaded into memory, and for import to load other duck source files or modules. Anyway this should be documented somewhere.

Another option I am considering in the case of runtime failures is to implement exception handling. I would see this as being similar to Java in using a throw exception instruction and providing some kind of try/catch block syntax. This could make use of a new exception data type.

While I have your attention, I would like some feedback on the other runtime error routines. I feel that the parser and lexer do a fairly good job at their tasks, but syntax errors are not always clear, so I would kind of like to keep those all in line for quality and accuracy.

I haven't been making many commits the past two days because I have started another local branch where I was trying to maximize performance to beat Python in a specific benchmark. I was able to accomplish this by stripping all error handling and making some other forced adjustments, but I wonder if any of these strategies could be used in the future, once the main branch is mature and stable enough. I encourage you to work on duck.c and study how it works now because there are undoubtedly a dozen better ways to work a VM. Another feature I implemented was getting the REPL script working better by hacking the parser to identify when a partial lexing was usable or when it had a fatal error, and was pretty satisfied and may merge that in or write it in C which might be better.

Now, most of this stuff doesn't really move the language standard forward, and it's rather difficult to re-merge parsed productions from the grammar when it is changed (which doesn't have to be the case) and I'm thinking of going ahead with 3 or 4 major additions/addendums, so I don't want to be too distracted by error handling but I do want to be sure that everything works okay and is easy to use. Segmentation faults should never happen and there should be more asserts thrown in to assure that but I also know I have to go back and write garbage collection routines eventually. Anyway, I want to add classes for real object oriented programming, callbacks and hooks for user types in static libraries, exception handling, fixing stuff like the omission of else if (maybe a switch case), adding the mod operator, allowing operator overloading (!) and so on. So there are still lots of things to do. My ideas for libraries are also pretty interesting, although they don't all need to be written in low-level code if they aren't platform facing. Like complex types or numerical types for working with super large or small numbers, useful for calculating 100 digits of PI or some form of e. But File IO and networking might be useful, too, and I have the team duck game engine (tedge) which is custom and proprietary that can be added for making 3D games once many of these issues are sorted out. It has useful stuff like collision and model loading.

And then I also have ambitions about implementing a duck => JavaScript compiler or another front end for cross-platform game programming between the PC and the browser without using emscripten, but this is all way forward in the timeline.

Anyway, sorry if most of this is off base and not so relevant to the drand and stack trace bugs, but I felt like I needed to express some of these ideas to feel organized, and I would appreciate your thoughts.

Best regards, Greg

[rpcope1]

Greg,

It's good to hear back from you, and I'm pretty stoked to hear your ambitious plans. I'll keep it brief for now just to touch base (as I'm going to board a plane real soon), but I'll have hopefully some more well formed thoughts later. First off, thanks for working on the stack trace and error handling stuff, I really appreciate your help. As you mentioned, it sounds like there's a lot of work to be done on the core language design, so don't let me distract you too much from that (I know how it feels, I get pulled around into multiple modules/codebases simultaneously at work). I think aiming to be faster than CPython is a really good goal to have (and isn't too outrageous, like trying to outperform LuaJIT lol). I'm pretty stoked to hear your ideas, especially with adding classes and operator overloading and such. Even though I'm not much of a front-end guy (yet) the Javascript part seems neat too; I think these are all really cool plans. As far as worrying about breakage, I'm happy to live on the bleeding edge, so don't worry too much about support on that end yet. :)

As far as my issue with the import, I realized I had my Python hat on, and as such, I probably should try and pitch out some of those preconceived notions while the language comes together. I'm starting to wrap my head around the codebase here, so I can move towards proposing a clean implementation of network and file I/O soon. As an aside, I think I need to look over the Dragon book again, lol. But yeah, I'll keep on studying here, and hopefully I should have some neat contributions coming in. Thanks for the lowdown, by the way; also if email is easier for communicating these kinds of details, I can give you my email address. I guess lastly, perhaps a Wiki might be a good way to document the raw language features as they evolve? Again, that should be something relatively straightforward, so I can definitely help with that.

While we're on the stream of thought thing, I was examining adding the +=, -=, etc. operators, and I have a feeling it's either simple, or subtly complicated (aren't they all). How do you feel about potentially pulling these into the language (they didn't seem to be there last time I pulled down from upstream)?

Oh, don't worry about wandering out beyond the topic at hand a little bit, I tend to be rather verbose myself sometimes, and would rather hear too much than too little; I certainly would far rather see the raw picture than get radio silence.

Best Regards, Robert