Pluvo : new hybrid scripting language

Pluvo is a functional and imperative programming language intended to be highly practical for scripting and CGIs, interpreted using a just-in-time compiler. Its hybrid dynamic and strict typing is flexible enough to allow duck typing. Its functions are, more specifically, closures, and it allows object orientation using prototypes.

From Sean B. Palmer.

Knowing he's a big fan of Python I expected a fair bit of influence - and there is, in fact the implementation is written in Python. Flexibility over typing was to be expected too, Sean's done a lot of work around RDF. Slightly surprising was Pluvo's syntax, which owes more to Bash.

By Danny Ayers at 2006-07-02 08:52 | Implementation | other blogs | 11959 reads

it uses prefix notation, but

it uses prefix notation, but supports infix by scanning a list of arguments until a "callable" value is found. is that going to work in general? it seems to imply, for example, that once you start using higher order functions you need to use prefix notation (since if you start using functions as arguments of functions, then it's unclear what is "the" function and what is an argument).

i can't remember what rebol does - is it similar to this? also an early article of graham's on arc had another solution for getting "infix for free". it might be interesting to compare them. on the one hand it's a silly little detail; on the other it seems like a really good solution to presenting prefix as infix would make s-exp based macro processing much more popular (didn't see anything about macros here though)

By andrew cooke at Sun, 2006-07-02 19:58 | login or register to post comments

Context-dependent parsing is evil

It's limited to declaring operator precedence in Haskell and Prolog. This is not nice but it works quite well in practice, until you want to implement a custom Haskell parser.

It's present in lots of very subtle lexing details in Perl; see toke.c file in the sources. This is bad because these cases are unexpected and the rules are tricky (some are heuristic).

It's present in C (type names must be distinguished from other names) and C++ (type names and template names must be distinguished, including qualified names). This causes programmer headaches in templates (the typename keyword and some uses of the template keyword exist because of this). This forces a precise C++ parser to implement the whole C++ type system and template system, which for perverse programs requires to know machine-dependent integer sizes for evaluation of integer constants.

It's horrible in Logo and Rebol because you must know the arity of every function to understand what is an argument of what.

It would be a very bad idea to decide between infix and prefix function application syntax at runtime, basing on which expression has evaluated to a function.

By Qrczak at Sun, 2006-07-02 23:09 | login or register to post comments

Are you shure that the

Are you shure that the compiler holds relevant information about callables / non-callables? I guess this is all runtime information. So parsing does not have to be context sensitive. The compiler might create an argument list only.

---

Maybe one can repair coördination for HOF by annotating some symbol to a callable in order to let the interpreter skip it when searching through an argument list for the first callable to use:

'f isa function

Here 'f is a callable f that will be handled as data and passed into the binary operator isa.

By Kay Schluehr at Mon, 2006-07-03 06:24 | login or register to post comments

By sebas at Wed, 2006-07-05 11:57 | login or register to post comments

Or Neko...

Or Neko, which is exactly meant for this kind of things.

By Nicolas Cannasse at Thu, 2006-07-13 16:19 | login or register to post comments

Lambda the Ultimate

User login

Navigation