Ideas and discussion for Regnus 5.4

The place to read and discuss the Regnus language and the updates to the specification.
Post Reply
User avatar
Ryan
Site Admin
Posts: 142
Joined: Wed Nov 11, 2009 pm30 8:19 pm
Contact:

Ideas and discussion for Regnus 5.4

Post by Ryan » Sun Jan 27, 2013 pm31 1:59 pm

It's been a little while since the last update to the core functionality of the Regnus language, but I've received quite a lot of ideas and suggestions from scripters in the meantime and have quite a few notes and thoughts written down, so this thread is to post some of the possible new features and changes in the next Regnus specification for discussion, and open conversation on any new ideas - please post below if you would like to suggest any additional functionality or comment on existing proposals. :)

1) A "COUNT" qualifier for automatic weighting of entries

This new qualifier would function in a similar way to the existing RATIO qualifier, but would allow an entry to be weighted according to the number of entries in a specified GROUP. This would probably work in the following way:

Code: Select all

GROUP Animal
ENTRY snake
ENTRY dog
COUNT Cat:##Cat;

GROUP Cat
ENTRY lion
ENTRY tiger
ENTRY felis silvestris lybica


In this example, the chance of the "snake" and "dog" entries would be 1/5 each, whereas the "##Cat;" entry would have a 3/5 weighting, as there are three entries in the "Cat" group specified before the colon. This would also take into account weighting within the named group, so:

Code: Select all

GROUP Animal
ENTRY dog
COUNT Cat:##Cat;

GROUP Cat
RATIO 4:lion
COUNT Tiger:##Tiger;
ENTRY felis silvestris lybica

GROUP Tiger
ENTRY white tiger
ENTRY golden tiger


In this example, a reference to the "Animal" group would give the "dog" entry a weight of 1/8, and the "##Cat;" entry would have a weighting of 7/8. If selected, the "Cat" group would then give a weight of 4/7 to the "lion" entry, 2/7 to the "##Tiger;" entry, and 1/7 to the "felis silvestris lybica" entry.

The potential problem with this, of course, is that it would be very easy to create a self-counting entry, which would potentially cause a parser to enter a state of infinite recursion. On the other hand, this may be mitigated by the fact that such situations should be very easy to identify and debug, even during script processing. This may need further consideration prior to implementation.

2) Improvements to parser efficiency

a) Pre-counting of entries

Currently, parsers count entries when necessary during script processing. This is unproblematic for small scripts, but with the recent trend towards very large scripts, it does create a large amount of processing time which could be reduced by counting all entries and weights for groups when a script is loaded, and storing this information to use during parsing. This would require slightly more processing and memory upon loading a script, but would potentially make parsing much faster.

A potential issue to consider is that this might not be an appropriate approach for web-based parsers, which are typically called once for each occasion in which randomised content is required rather than being stored in memory between parsings, and so could potentially be made slower rather than faster by this change.

b) Pre-storage of definition qualifiers

Currently in the default parser layout, every use of the ~ AGC causes the parser to seek for matching MULTI qualifiers in the script, which is clearly an inefficient process, especially when no MULTI qualifier exists! I would suggest that as of the next specification, all MULTI qualifiers are pre-loaded and the pluralisation function simply checks against loaded definitions before using the English default forms, which could make major processing speed improvements for some scripts. This should also apply to the REFER and DEBAR qualifiers.

3) An auto-grammar function to modify text-case

Currently, the ^ AGC is a useful way to capitalise a single following character. However, there may be times when it is useful or necessary to change the case of a section of text within a script, either to force uppercase, force lowercase, or indeed to apply namecase (first letter of each word capitalised).

One possibility would be to use the existing ^ AGC in combination with bracketing characters to achieve the different effects. Assuming that parantheses would be used, this might work in the following way:

Code: Select all

ENTRY Hello there, I am ^elvis ^presley!
BLANK Returns: Hello there, I am Elvis Presley!

ENTRY Hello there, I am ^(elvis presley)!
BLANK Returns: Hello there, I am Elvis Presley!

ENTRY Hello there, I am ^^(elvis presley)!
BLANK Returns: Hello there, I am ELVIS PRESLEY!

ENTRY Hello there, I am ^.(Elvis Presley)!
BLANK Returns: Hello there, I am elvis presley!

ENTRY Hello there, I am ^.Elvis Presley!
BLANK Returns: Hello there, I am elvis Presley!

ENTRY Hello there, I am ^^elvis presley!
BLANK Returns: Hello there, I am ELVIS presley!


4) An "include" functionality (to help organisation of large scripts during development)

A recent suggestion is some form of "include" functionality, which would work in a similar way to other programming and scripting languages, in that it would cause an external script to be included in the current script and treated as a single script.

It is already possible, of course, to use the $ RTC to reference content in external scripts, and this already allows for all of the functionality which an include function would provide. However, the subtle difference is that using a reference creates and additional recursion and returns fully processed parsed content from an external script, as the two individual scripts are effectively "blind" to each other's contents. An include function would actually cause the external script to be loaded into memory as if it was part of the current script, meaning that its groups would be accessible in all the usual ways, without having to create handler labels in the second script to grant access to its content.

This would be relatively easy to implement, but might not be desirable as it essentially duplicates (though in a simplified fashion) existing functionality, and also, would potentially cause issues as the included script would not necessarily be complete and valid, and would cause duplicate metadata qualifiers if it were to be a complete valid script. External scripts in this case would be more likely script "fragments" containing only groups of entries with no labels, for instance, so it may be necessary for simplicity of debugging to include new metadata and specify that a particular file is deliberately a fragment rather than a complete script.

5) Parser functionality to understand file paths independently of environment

Currently, the $ RTC allows external scripts to be referenced, including a full file path, but these file paths may vary depending on the system on which the script is run. This is notably inconvenient, for example, when authoring a script on a Windows system, in which directories are separated with backslash characters, but putting that script into use on the web, for which forward-slash characters are used.

As Regnus scripts should be in themselves entirely platform-independent, the suggested behaviour should be for one convention to be used in Regnus scripts, and for parsers to translate to the native environment. The exact implementation of this will need to be decided.

6) Extend functionality of ~ AGC and MULTI qualifier to match phrases (rather than single words)

Currently, the ~ AGC will only match a single word, but there are certain cases in the English language in which it might be useful to pluralise a noun phrase in which the noun is not the final word. For example, "drop of water~" would be (correctly, but not very usefully) pluralised to "drop of waters".

Along with the already-suggested improvements to MULTI parsing efficiency (see point 2b, above), it should be relatively simple to allow the MULTI qualifier to match whole phrases rather than single words, for example:

Code: Select all

MULTI drop of water:drops of water


One side-benefit of this approach is that it would also very potentially present the possibility to exploit the MULTI qualifier for novel uses outside of pluralisation.

thunderclap
Posts: 16
Joined: Mon Jan 28, 2013 am31 1:35 am

Re: Ideas and discussion for Regnus 5.4

Post by thunderclap » Mon Jan 28, 2013 am31 2:05 am

Ryan wrote:A "COUNT" qualifier

The potential problem with this, of course, is that it would be very easy to create a self-counting entry, which would potentially cause a parser to enter a state of infinite recursion. On the other hand, this may be mitigated by the fact that such situations should be very easy to identify and debug, even during script processing.

It is true that it could potentially be easy to make a self-counting entry. But on the other hand looking at the animal example you gave, it's starting to seem like it would also be very illogical for someone to actually make a self-counting entry.

Bad organization of groups could cause it. But otherwise, it wouldn't make a whole lot of sense to have Tiger reference Cat for example. More complicated scripts could be less clear in that regard, I'm sure. But there would still most likely have be an organizational/logic problem with how the groups are set up in the first place for a self-counting entry to be likely, I think. :rubchin:

The auto-capitalization shown above would work very nicely. This would be able to title case a group call for example very easily. :)

Ryan wrote:understand file paths independently of environment

I'd suggest putting an example in the tutorial of how to use paths as well, as right now the tutorial doesn't even mention that file paths can be used in the first place ;)

User avatar
Ryan
Site Admin
Posts: 142
Joined: Wed Nov 11, 2009 pm30 8:19 pm
Contact:

Re: Ideas and discussion for Regnus 5.4

Post by Ryan » Mon Jan 28, 2013 pm31 4:18 pm

thunderclap wrote:I'd suggest putting an example in the tutorial of how to use paths as well, as right now the tutorial doesn't even mention that file paths can be used in the first place ;)


That's a good idea - I'll add it to my site to-do list!

thunderclap
Posts: 16
Joined: Mon Jan 28, 2013 am31 1:35 am

Re: Ideas and discussion for Regnus 5.4

Post by thunderclap » Sat Feb 02, 2013 am28 4:46 am

I had another idea. You know how that CYOA script always has "turn to page X" at the bottom? Having some kind of RTC that could make text clickable to continue generation could be interesting, especially if stored values could be remembered.

If that does get added, it would probably be nice to have some way of viewing the whole chain of what was generated. Although that sounds like it'd be more of a parser feature.

James Cracknell
Posts: 8
Joined: Mon Nov 30, 2009 am30 1:15 am

Re: Ideas and discussion for Regnus 5.4

Post by James Cracknell » Sun Feb 03, 2013 pm28 7:49 pm

I would endorse all the added functionality suggested, particularly anything which would improve efficiency since my script Breaking News is one of the biggest ever created and I'm having a lot of trouble getting it to run on my website the-taxman.co.uk without it causing the site to time out!


User avatar
Ryan
Site Admin
Posts: 142
Joined: Wed Nov 11, 2009 pm30 8:19 pm
Contact:

Re: Ideas and discussion for Regnus 5.4

Post by Ryan » Tue Mar 05, 2013 pm31 4:48 pm

It seems that the current set of suggestions are quite popular, so unless anyone has anything additional to add, I may consider starting work on implementing some of these soon. :)

Ryan

User avatar
Ryan
Site Admin
Posts: 142
Joined: Wed Nov 11, 2009 pm30 8:19 pm
Contact:

Re: Ideas and discussion for Regnus 5.4

Post by Ryan » Tue Mar 26, 2013 pm31 6:07 pm

thunderclap wrote:I had another idea. You know how that CYOA script always has "turn to page X" at the bottom? Having some kind of RTC that could make text clickable to continue generation could be interesting, especially if stored values could be remembered.

If that does get added, it would probably be nice to have some way of viewing the whole chain of what was generated. Although that sounds like it'd be more of a parser feature.


This wouldn't really be a feature for the Regnus language, as it wouldn't be something that could be done at the time of script processing. But it should certainly be possible to create an (X)HTML-based CYOA script using the PHP/Web parser that would function like this, simply by having the script output links at the end of each page to call back to the index page with new arguments to be passed to the parser...

Actually, that's a pretty cool idea. ;)

Ryan

User avatar
Ryan
Site Admin
Posts: 142
Joined: Wed Nov 11, 2009 pm30 8:19 pm
Contact:

Re: Ideas and discussion for Regnus 5.4

Post by Ryan » Mon Apr 01, 2013 pm30 1:35 pm

Update:

I've now experimented with all of the suggestions for the 5.4 specification, and implemented the new features and improvements in several of the existing parsers.

All of the new features suggested above will be included in the new specification, with the exception of the "include" functionality, which I've decided needs to be more carefully thought through in order to make sure that it works elegantly. I'll certainly be looking into adding this for the next specification update (and will likely discuss it here first), but there are several issues which need to be considered before implementation.

The other new features and efficiency improvements all seem to be working very well though, and (pending an update to the documentation and site) I'm expecting to be able to release the new spec and parsers very soon. :)

Ryan

Post Reply