Re: [s-d] dice server enhancements

[Joel Uckelman <uckelman@xxxxxxxxx>]

Thus spake Daniel Lepage:
> 
> 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.

I refuse to use Python because it won't let me format my whitespace the
way I want; you can probably guess how eager I'd be to create something
that I'd refuse to use myself. Sorry, no Python syntax.

On the other hand, the most common expressions (die rolls with some
simple arithmetic) are going to look the same so long as we use
infix notation (whee, PostScript!). It's not like you could tell
whether {{4d3+d20}} is in a Python or C or Perl dialect anyhow.

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

Good idea. I'll add that.

> > 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?

I thought about that, but couldn't come up with one I liked. {!{ }!}
is hard to look at. {{! }} could be ambiguous with the logical negation
of whatever is in the block. I thought of !{{ }} myself, but then you're
stuck guarding your exclamation points in text. << >> looks too... I don't
know, I just didn't like it. Having only two modes seems cleaner to me
anyway.

Maybe I'll make 'silent' a synonym for (), so you can put it at the end
of blocks? I'm not sure which is best, but this is a design decision that
would be easy to change.
 
> > 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 ()?

Yeah, that's the intention. There's no natural value for a function
declaration to have; if it did return a value, say, 42, then most of
the time you'd have to do something to clear the return value of the
block, which would be annoying.
 
> > 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?).

Sure, if you think it would be useful. Lists aren't a scarce commodity.

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