intfiction.org

The Interactive Fiction Community Forum
It is currently Sat Dec 15, 2018 7:49 am

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
 Post subject: Re: Dialog
PostPosted: Tue Dec 04, 2018 4:50 pm 
Offline

Joined: Mon May 10, 2010 7:32 am
Posts: 61
Once again, I'm impressed. I love the slash expressions a lot because they reduce parser code to a minimum.
Thx for the great work!


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Thu Dec 06, 2018 6:45 am 
Offline

Joined: Sat May 03, 2008 11:32 pm
Posts: 302
This looks very cool!

Dannii wrote:
For an interactive debugger - maybe you could borrow from ZILF's debugger?

Indeed. The Visual Studio Code extension for ZIL adds several IDE features, including a source-level debugger using ZLR as the backend. The debugger is fairly easy to adapt to other languages, as long as you can generate a debug info file mapping the Z-code addresses back to source lines.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Thu Dec 06, 2018 7:35 am 
Offline
User avatar

Joined: Thu Aug 22, 2013 2:48 pm
Posts: 108
Version 0c/02 (download link) fixes a compiler bug in '(status bar width $)'. The bug made scored games, including Cloak of Darkness, crash on some interpreters.

_________________
Dialog. Tethered.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Thu Dec 06, 2018 3:18 pm 
Offline

Joined: Mon May 10, 2010 7:32 am
Posts: 61
Dannii wrote:
For an interactive debugger - maybe you could borrow from ZILF's debugger?


Parser tracing (feature activated by typing (trace on) somewhere in the story file already gives a very good feedback what's going on. It traces all triggered rules and writes out the actual line of their code. This is far better than any other if debugger I've seen so far, because it spans all rules including parsing.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Thu Dec 06, 2018 3:33 pm 
Offline

Joined: Sat May 03, 2008 11:32 pm
Posts: 302
Mikawa wrote:
It traces all triggered rules and writes out the actual line of their code. This is far better than any other if debugger I've seen so far, because it spans all rules including parsing.

I implemented this for ZILF also, but I found it stopped being useful once games reached a certain size, because the extra code and text for tracing made them exceed the Z-machine memory limits.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Fri Dec 07, 2018 2:36 am 
Offline
User avatar

Joined: Sun Nov 22, 2009 12:58 pm
Posts: 803
Location: Malmö, Sweden
Oh, and by the way (with apologies if this has already been addressed), what are your plans for the language further on? Is it gonna be exclusively z-Machine and/or text only?

_________________
~Björn Paulsen


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Fri Dec 07, 2018 3:34 am 
Offline
User avatar

Joined: Thu Aug 22, 2013 2:48 pm
Posts: 108
For now, I'm going to focus on the Z-machine backend, text-only. The compiler needs some rework, and there are bugs to sort out.

Eventually I hope to add Glulx support, as well as the basic "display picture" stuff.

But I think it makes sense to at least start on the debugging backend before that, since that is going to reveal flaws in the frontend/backend interface, and those flaws are going to be less painful to address if there's just one regular backend.

_________________
Dialog. Tethered.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Fri Dec 07, 2018 5:54 am 
Offline
User avatar

Joined: Wed Oct 14, 2009 4:02 am
Posts: 2568
Is there a way to have inline assembly of some sort? If so then multimedia (and a whole lot of other stuff) can just be implemented in libraries. (And indeed, many of the the built-in predicates arguably should be too.)


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Fri Dec 07, 2018 9:08 am 
Offline
User avatar

Joined: Thu Aug 22, 2013 2:48 pm
Posts: 108
On the contrary, I think it's important not to go down that path. Inline assembly results in a creole of VM-dependent, low-level code and story-level predicates. Not only does that lead to platform lock-in effects, it's also more difficult for the compiler to optimize, and less readable.

One of my explicit goals was to make a language where story authors could read, understand, and modify library code. I think many Inform 7 programmers hesitate to even look at the I6T code underpinning their stories, let alone modify it. And who can blame them, when those routines are written in a completely different language? I'd even posit that there are two castes of Inform 7 programmers: those who understand how the system works under the hood, and those who regard it as black magic, and consistently need to turn to the former group for advice. And this can be authors with long-term experience of Inform 7! Due to the mixture of languages at different levels of abstraction, there's this huge threshold in the middle of the learning curve, pushing people back into the lower caste. And I emphatically want to avoid that.

I hasten to add that there are other aspects of Inform 7 that I think are brilliant. But this particular design choice has always bothered me.

Of course, Dialog also has inaccessible low-level stuff under the hood, but the point is that the low-level stuff doesn't have anything to do with the story. Both Inform 7 and Dialog have the same overall stack-up of 1. story, 2. library and parser, and 3. low-level machinery. Inform 7 puts the language barrier between levels 1 and 2. Dialog puts the barrier between levels 2 and 3. I argue that the latter is better because the library and parser are so deeply intertwined with the story; The story author must be able to understand and adapt them, and to debug levels 1 and 2 together, at a high level of abstraction. To allow inline assembly is to allow the incomprehensible stuff to creep up through the levels.

So, in addition to the technical reasons I mentioned at the top, this boils down to a personal desire to let the author see what's going on. And I've argued that the way to keep the relevant layers comprehensible and transparent is, perhaps counter-intuitively, to keep the low-level stuff hidden: To maintain a strict separation between high-level (story, library, parser) and low-level (z-code, optimization), and to ensure that this interface is clean and well documented.

_________________
Dialog. Tethered.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Dialog
PostPosted: Fri Dec 07, 2018 10:34 am 
Offline
User avatar

Joined: Wed Oct 14, 2009 4:02 am
Posts: 2568
Pulling the parser into the high level is great. But I don't see why that has to mean the author can only access a lowest common denominator model of the VM. Especially when it's usually very simple, far far simpler than the parser is.

For example, with text formatting, why have separate predicates for bold, italic, etc. If you don't want inline assembly, what about predicates that correspond to the operations of the VM: a "set text style" predicate that takes a parameter for the style. (Rather than then implementing those rules manually in the compiler, I'd use assembly myself, but you do what you want.) The "status bar" predicate is the kind of magic I would've thought you wouldn't want from what you just wrote. To set the height and clear the window, and reset the cursor... Why should that be one operation in the compiler rather than a library function which can be modified as needed? It's hiding things from the author, and not just in library files, but in the compiler itself!


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group