Re: [s-d] dice server enhancements

[Daniel Lepage <dpl33@xxxxxxxxxxx>]

On Dec 17, 2006, at 4:50 PM, Joel Uckelman wrote:

> It sounds like what you want is "text mode" and "code mode",  
> combined with
> statefulness for the interpreter over the whole message.
>
> What would you think of having something which is more or less a  
> subset
> of C or Perl, with all of the special die-rolling functions as  
> built-ins?

I'd like that, though I'd prefer a subset of python, as I've found  
that it's generally easier for non-programmers to use bits of python  
than bits of other languages. Unfortunately, writing parsers for  
python is a bit tricky because of the indentation-based blocks, and  
the 'text mode' delimiters are probably easier to get working with  
clear delimiter characters.

> So, you'd do this:
>
> {{
>    if (d6 > 4) {{Wonko dies. E is trapped in limbo for {{2d3}}  
> ndays, and will emerge then on square ({{d20}},{{d20}}).}}
>    else {{Wonko survives the attack. E gains {{4d3+1d2}} experience  
> and finds a {{perm("Sword","Axe","Stick")[0]}} of {{perm 
> ("Smiting","Power","Suckiness")[0]}}
> }}
>
> Or something like it. The default mode would be text, and each set  
> of braces
> toggles to the opposite mode. You'd also have a positional variable  
> $n,
> corresponding to the output of the nth invocation of code mode.

Yeah, this would work. {{Wonko is trapped for {{2d3}} ndays.}} could  
be an expression that evaluates to the string produced by running  
that block through the engine; this would also allow you to do things  
like
{{
first 1 perm({{Wonko gains {{1d6}} points.}},{{Wonko loses {{2d5}}  
Charm.}}, {{Wonko {{first 1 perm("Freezes","Catches Fire")}} }})
}}

Incidentally, a "choice" builtin would also be handy, with "choice l"  
being equivalent to "first 1 perm l".

> I'd drop the 'let' from assignment, so you'd have {{ x = 5 }}, like  
> in any
> normal language. Array indices would be easy, just suffix [i] onto  
> any list.
>
> The "return" value of a code block {{ }} would be the value of the  
> last
> expression to appear in it. I'm not sure what to do about blocks  
> where you
> don't want a return value, e.g., where you're doing some setup.  
> That could
> be done by having a 'silent' operator:
>
> {{ silent x = 5 }}
>
> or just by ending such blocks with an empty list:
>
> {{ x = 5 ; () }}

You could also change the delimiters - maybe use {{! }} or {!{ }!}  
for silent code?

> We could define functions like this:
>
> {{ sub foo(x,y,z) { x + y + z } }}
> I drink {{ foo(d6,1,4d3) }} shots of tequilla.

That'd be great. The value of a subroutine declaration is assumed to  
be ()?

> More comments?
>
> (Sorry for spilling all of this stuff onto the game list, for those of
> you who don't care about the minutae.)

Perhaps we need a fourth list for discussing such things (spoon- 
technical? spoon-hacker?).

-- 
Wonko

_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss