Ideas and discussion for Regnus 5.5

The place to read and discuss the Regnus language and the updates to the specification.
veryalien
Posts: 13
Joined: Wed Apr 16, 2014 am30 9:13 am

Re: Ideas and discussion for Regnus 5.5

Post by veryalien »

Ryan wrote:
veryalien wrote:Is there any way to force a particular group entry without it being a random result? My brain says that Instead of just using Animal; to always get a random entry from the Animal group, a simple extension would be Animal[2]; to always access entry 2 in the group. Sorry if that's already possible, if it is I didn't find it yet. Maybe this is already possible using other methods?


This isn't currently possible as a built-in function - the way to achieve the effect, if desired, would probably be to add numbered labels to each entry in a group and then use a label reference to return the desired result.

I have to admit that I'm not sure I can think of any obvious use for this type of functionality, though? If you already know the result you want to return, would it not be easier to simply include it as text, rather than via a reference?

I was looking for a way to consistently use a reference to the same text, but be able to use the group entries randomly when needed. Preferably without hard-coding any of the texts.
For example days of the week, months of the year and signs of the zodiac. They all have a particular order within their 'groupings', but you can refer to each individual instance of an element in a random order. You might want to generate a weekly plan running exactly from Monday, Tuesday, Wednesday ... through to Sunday. But somewhere else a random day of the week is used. Or a yearly almanac running exactly from January, February ... to December and then referring to random days within random months. I was actually thinking of automatically generating the groups from some other data and it would be more convenient and elegant to re-use the texts instead of hard-coding anything.
Ryan wrote:
veryalien wrote:Automatically stepping through all group entries in an ordered sequence each time a group is accessed would also be a nice feature. Regnus keeps an index of which entry was last accessed and returns the next one in the sequence.


Again, I'm not sure I can think of an obvious use for this, since you're achieving a non-random result? It's already possible to ensure the return of every entry in a group in a random order, but if the object is to return the entries in a set order, would it not be simpler to just add those entries directly to the content, rather than via a reference?

If the aim is to ensure that three selected entries remain in the same order once generated, you could do something like this:

Code: Select all

GROUP Example
ENTRY <Repeat Three Names In The Same Order>#>(0):(#&Names;, #&Names; and #&Names;); always referred to themselves in the same order: ##[0];.

GROUP Names
ENTRY Tom
ENTRY Dick
ENTRY Harry



Like the examples above, regarding order in a group, even 'Tom, Dick and Harry' has soon kind of order to it. Harry, Tom and Dick (even when consistent) isn't really what I was looking for. But, as you mentioned, you might as well just write every Tom, Dick and Harry as plain text as there isn't anything random or dynamic there. However, thanks for your eyample, I did one tweak on that to put each name in a separate store. You could then consistently refer to the initially generated order by using the stores ##[0];, ##[1]; and ##[2]; together or individually. If you had some lists containing various aspects of Dick[0], Harry[1] and Tom[2] you could separately, but consistently, refer to the Tom[2] list, Harry[1] list and Dick[0] list, just by using the individual stores.

Code: Select all

GROUP Example
ENTRY <Repeat Three Names In The Same Order>#>(0):(#&Names;);, #>(1):(#&Names;); and #>(2):(#&Names;); always referred to themselves in the same order: ##[0];, ##[1]; and ##[2];.

GROUP Names
ENTRY Tom
ENTRY Dick
ENTRY Harry

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

Re: Ideas and discussion for Regnus 5.5

Post by Ryan »

veryalien wrote:

Code: Select all

GROUP Example
ENTRY <Repeat Three Names In The Same Order>#>(0):(#&Names;);, #>(1):(#&Names;); and #>(2):(#&Names;); always referred to themselves in the same order: ##[0];, ##[1]; and ##[2];.

GROUP Names
ENTRY Tom
ENTRY Dick
ENTRY Harry



Yep, that's certainly more flexible than my example. :)

veryalien wrote:I was looking for a way to consistently use a reference to the same text, but be able to use the group entries randomly when needed. Preferably without hard-coding any of the texts.


I'm not convinced that avoiding hard-coded data is necessarily an appropriate approach in Regnus generally, as it's a language which is almost entirely structured around hard-coded data! Although of course avoiding duplicate data in a script is often a good idea in order to maintain ease of editing...

As a thought, you could actually use almost the same method as in your other example for storing the month names in one place but being able to access them throughout the script:

Code: Select all

GROUP Example
ENTRY <Example>{#_(Setup Month Data);}The third month of the year is ##[3];. A randomly selected month is ##[##Numbers;];.
ENTRY <Setup Month Data>#>(1):(January);#>(2):(February);#>(3):(March);#>(4):(April);#>(5):(May);#>(6):(June);#>(7):(July);#>(8):(August);#>(9):(September);#>(10):(October);#>(11):(November);#>(12):(December);

GROUP Numbers
ENTRY 1
ENTRY 2
ENTRY 3
ENTRY 4
ENTRY 5
ENTRY 6
ENTRY 7
ENTRY 8
ENTRY 9
ENTRY 10
ENTRY 11
ENTRY 12


You could also use the REFER functionality to actually name the numbers something more useful should you wish, so you could use one set of names for the months in your script, but read in alternative names if necessary for the actual output, and the slot numbers would always let you return the months either randomised or in order, as necessary. :)

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.5

Post by Ryan »

Update:

I've now implemented points 3) and 4) in a beta build of the VB6 parser.

For point 3), I've opted for the following syntax, for consistency and simplicity:

Code: Select all

START <Example>Hello world!


(I've also found a fixed a few glaring bugs in the existing parser implementation of labels while adding this support, which will probably be fixed now with the release of parsers supporting the 5.5 spec.)

After some consideration, the implementation I'm probably going to use for point 4) is to support a set precision of fractions (currently a minimum division of 1/1000, or 0.001), rather than to support arbitrarily minute fractions, on the basis that it's very simple to implement, whereas there would be some additional loading overhead in order to support varying levels of precision (as the script would first need to be read through to determine the smallest precision), and since floating point rounding issues would make particularly small fractions potentially inconsistent across different platforms anyway (and I don't think there are likely to be many uses for fractional values smaller than 0.001 for the majority of script authors), this seems currently to be the best option.

I'm planning to try building and testing implementations for inline entry selections (ala point 2)) and random numeric value generation (ala point 5)) next.

(I can already see that the 5.5 specification is going to require some major edits to the tutorial. :P)

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.5

Post by Ryan »

Further update: points 3) and 4) are now also functioning in the QB4.5 and PHP parsers.

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

Re: Ideas and discussion for Regnus 5.5

Post by Ryan »

Another update:

I've now completed an initial implementation of a new type of expression which is parsed as a form of dice notation for generating random numeric values (ala point 5)) in all three parsers which I maintain. I've opted to avoid support for more complex mathematical parsing (I suspect that could rapidly spiral into a whole new language all of its own!), but it will certainly support integer addition, subtraction, multiplication (including exponents) and division, as well as paranthesised sub-expressions.

So, the current plan is to support expressions such as:

Code: Select all

GROUP Examples
ENTRY The troll has ##{D6}; hit-points!
ENTRY You have discovered a +##{2D10}; sword of smiting!
ENTRY You discovered the Amulet of Yendor in level ##{3D6+4};!
ENTRY I've warned you about the over-complexity of your dice notation at least ##{(2D6+1)×(4D10-D8)}; times!


(Note that the actual multiplication symbol is supported as above, as well as the letter "x" - the asterisk character will also work, should you wish, but as it's already used in Regnus as a character escape, as a general rule, I'd recommend against its use for these types of expressions, to avoid potential ambiguities.)

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

Re: Ideas and discussion for Regnus 5.5

Post by Ryan »

Update: point 6) updated with some further considerations.

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

Re: Ideas and discussion for Regnus 5.5

Post by Ryan »

Update: I've now coded an implementation of the inline entry selection suggested in point 2) - actually not a trivial addition, as it requires quite a lot of sub-parsing to ensure that inline groups can be properly nested with the desired results.

The implementation I've opted for is to add the new functionality to the existing literal expression syntax, using the backslash character (I decided against the original suggestion of the broken bar character on the basis that its character code varies across different text encodings, which would mean that either the parsers or even the Regnus language itself would no longer be able to be encoding-agnostic). Very little additional processing overhead is added to the existing literal expression parsing for expressions which don't use the new functionality, so this seemed to be the most elegant design. Any existing scripts which use backslash character in a literal expression (are there any?) will need to be escaped with overstep characters, of course.

So, the following constructs are now valid in the next generation of parsers:

Code: Select all

ENTRY ##(Hello\Goodbye); world!
ENTRY ##(This is a forward slash: /\This is a backslash: *\);
ENTRY Nested literal expressions are ##(cool\fun\##(convoluted\messy);\efficient);!


I think that I'm going to pass over point 1) again for this update (for a variety of reasons), but my plan is to give some more consideration to point 6) next.

Any further thoughts welcome. :)

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.5

Post by Ryan »

Update:

I've now spent a couple of days playing around with an implementation of the unparsed entries suggestion, and I've come to the conclusion that there are too many limitations to the basic proposal, and adding full support for unparsed entries (oversteps working in reverse, a new RTC to return unparsed text, the ability to choose specific reserved characters to escape, etc.) would be an extensive addition that could ultimately be inelegant and over-complex for its intended use.

I'm currently toying with the simpler idea of allowing an alternate syntax for labels to be selected, specifically for the purpose of making (X)HTML generation better supported. My thought is something along the lines of:

Code: Select all

LABEL <>
START <This is a label!>Hello world!


Code: Select all

LABEL []
START [This is a label!]Hello world!


Of course, for back-compatibility with existing scripts, the triangular brackets would need to remain the default, but the ability to optionally switch to square brackets would then free up the triangular brackets to be used in HTML-generating scripts without the need for escaping.

My only concern is that this is a potentially somewhat inelegant solution in itself!

All thoughts welcome. :)

Ryan

veryalien
Posts: 13
Joined: Wed Apr 16, 2014 am30 9:13 am

Re: Ideas and discussion for Regnus 5.5

Post by veryalien »

Ryan wrote:Of course, for back-compatibility with existing scripts, the triangular brackets would need to remain the default, but the ability to optionally switch to square brackets would then free up the triangular brackets to be used in HTML-generating scripts without the need for escaping.

My only concern is that this is a potentially somewhat inelegant solution in itself!


I don't know if the following approach is too simplistic, but it might be easier to implement:

I never use labels other than at the start of a line. I think restricting labels to the start of a line wouldn't be a bad restriction for most Regnus scripts.
On lines where there are more than one pair of angled brackets <...> ... <...> ... just force the first pair to always be interpreted as a label and the rest are just normal < and > characters. So for HTML you would always need a label which allows all HTML tags on the rest of the line to be output as normal characters.
Or, perhaps better, allow a 'dummy label' with exactly the text <HTML> which denotes, for the current line, that it is in HTML format and all pairs of < and > characters (apart from the first pair) are just normal < and > characters.

Something like:

Code: Select all

GROUP markup
ENTRY <LABELNAME><HTML>Normal text.<i><b>This text will be in bold italics!</b></i>
ENTRY In fact, on lines where there is only normal text, <LABEL2>labels could still be anywhere!

Post Reply