F # fournit une combinaison de "sécurité de type, concision, performances, expressivité et scripts".
google rapide. F3, script javaFX, Linden Scripting Language (script pour la seconde vie), Contrairement au commentaire sur la première réponse, F # peut être utilisé comme langage de script http://blogs.msdn.com/chrsmith/archive/2008/09/12/ scripting-in-f.aspx
Felix, Tuga, CFGScript, Talc, Angelscript, et je suppose qu'il y a plus que cette recherche rapide.
Douglas
Généralement, les langages à typage statique sont des langages compilés. Je suppose que la raison en est que l'analyse statique des types est plutôt coûteuse et que vous devez examiner en profondeur tout le code que vous traitez. Après avoir fait cela, il semble inutile de ne pas écrire toutes ces informations dans un fichier, de sorte que vous n'ayez pas à le refaire la prochaine fois. On se retrouve donc rapidement avec un langage compilé.
Par contre, transformer un langage compilé en un langage "non-compilé" est assez facile. Vous ne stockez simplement pas les résultats de la compilation, mais vous les exécutez directement. Un compilateur que je connais qui fournit un tel wrapper est GHC, le compilateur Haskell standard. Vous pouvez ajouter #!/usr/bin/runhaskell à vos fichiers source, puis exécutez-les directement. Et puisque vous prévoyez d'être loin de la norme, Haskell semble être un ajustement parfait ;). Mais attendez-vous à un temps de démarrage assez important pour vos scripts, car toute l'analyse et l'optimisation du "temps de compilation" n'est pas gratuite.
Haskell n'est pas fait pour les scripts shell et c'est un langage fonctionnel, donc si vous ne l'avez jamais vu auparavant, cela peut prendre un certain temps pour s'y habituer. Mais il a très peu de surcharge syntaxique et la force des langages fonctionnels est l'abstraction, donc je ne vois pas pourquoi vous ne pourriez pas créer une bibliothèque qui rende les scripts shell amusants. Il existe même un shell Haskell expérimental, mais cela semble être plus une preuve de concept qu'une vraie solution.
Généralement, je dirais que la surcharge de toute l'analyse de type est importante, mais je suggérerais que vous choisissiez votre langage compilé à typage statique préféré et que vous recherchiez un wrapper comme runhaskell pour exécuter les scripts qui y sont écrits.