Back to Questions
1.8k
views18
comments
Eval
f#

So, as I have read here, there is no Eval like in Lisp, Tcl or Perl. Why is that? Is that because F# syntax is complexer then that of Tcl? Just curious.

.

Hi,
there is a limited support for this feature thanks to the evaluation of LINQ expressions. You can find some examples on the Hub here: [link:cs.hubfs.net]

In general, it would be possible to extend the example above to work for arbitrary quoted F# code (code wrapped inside the <@ .. @> symbols, which is compiled to some data representation of the F# AST). This isn't currently possible, probably because it's not that needed/requested feature and it isn't <i>that <i>useful for a language like F#. But I guess it will sooner or later be possible. Having "eval" in languages that are mostly interpreted is easy, so that's I guess the reason why many (originally) interpreted languages support this. Adding "eval" that takes a string as an argument to F# would basically require distributing the whole compiler with the F# runtime, which just looks a bit weird.

By on 3/4/2009 5:34 AM ()

Adding "eval" that takes a string as an argument to F# would basically require distributing the whole compiler with the F# runtime, which just looks a bit weird.

I come from the Ruby world, and I'll toss in my vote for the opposite of this statement. Having the compiler available in the language at runtime is completely normal, and not having it is the weird case. I realize there's a family of legacy languages that don't do this (Java, C#), but that doesn't mean that F# should follow their example.

Also, I don't at all understand the "F# is for scientific programming" idea. I don't do scientific programming - I'm intrigued by F# as a language for traditional user-facing web apps. In particular, I'm thinking that F#/{Moon,Silver}light is an interesting place.

By on 3/4/2009 9:55 AM ()

Having the compiler available in the language at runtime is completely normal, and not having it is the weird case.

If I write an application and send it to other people, I usually don't want them to install F#. That's a problem with Ruby, Perl... as a user, I prefer have a binary file that contains everything, instead of downloading a new compiler/interpreter every time.

However, I agree that an eval function could be very powerful. That would be great if the compiler exported an eval "string -> obj" function. Applications that want this eval function would link to the compiler, the others would not.

I agree the quotation eval function is way safer, cleaner, and so on, but it sometimes doesn't fit.

Laurent.

By on 3/5/2009 3:34 AM ()


If I write an application and send it to other people, I usually don't want them to install F#.

Agreed.

Packaging the compiler along-side your application, or having it as part of the .NET Framework would ordinarily be the recommended way of dealing with dependencies.

regards,

Danny

By on 3/5/2009 8:38 AM ()

>> Also, I don't at all understand the "F# is for scientific programming" idea. I don't do
>> scientific programming - I'm intrigued by F# as a language for traditional user-facing
>> web apps. In particular, I'm thinking that F#/{Moon,Silver}light is an interesting place.

That's mostly my case as well - and I think there is a lot of potential in F# for various types of applications (definitely including web apps, since this is now a very important area). However, I guess the "scientific applications" area was one of the primary <i>original<i> motivations. Now it depends on us (the users) how we'll want to use F# and how we'll want it to evolve. >> Eval I think it may be useful sometimes, but having worked on Phalanger (PHP compiler for .NET) for some time, I have to say that doing eval in a language compiled to standard .NET code is totaly crazy. For example, you'd expect to be able to capture local variables, perhaps capture "this" reference (PHP does that..) and some other things. F# can never do that (wihtout making "eval" part of the language, which I hope won't hapen). On the other side there could be a function "<b>string -> Expr<'a></b>" that would parse provided string and you could definitely use it with other functions for working with qutoations, so you could build a quotation that captures some local variables if you wanted to (using the "splicing" operator "%"). This would be more lightweight and it could be powerful enough for most of the applications. BTW: In case you want "eval" that does more than just compilation of simple F# expressions, there is also CodeDOM, that allows you to generate & compile code at runtime. It is used mostly for ASP.NET, but there are certainly other uses: <A href="/blogs/tomasp/archive/2006/08/13/475.aspx">http://cs.hubfs.net/blogs/tomasp/archive/2006/08/13/475.aspx</A>

By on 3/5/2009 3:52 AM ()

I think what might be interesting is a typesafe eval, something more like this:

let desiredSignature = 'a -> 'b -> 'c -> string

let myNewFunction = Eval.string_to_function desiredSignature "
let myNewThing x y z =
"tasty goodness"
"

And if the results don't match the desired signature, throw an exception.

By on 3/5/2009 9:44 AM ()

Since F# has nice reflection capabilities, the Eval function should return an obj type. The user would then unbox it, or match it with different types. That's type safe.

On a related topic, I wish I could easily embed F# in an application. It would be a great replacement of Lua (or Lisp as in Emacs). This is a bit different of the classical Eval function, because the script should be able to call some functions defined in the host application, and vice-versa.

Laurent.

By on 3/5/2009 3:02 PM ()

I think it may be useful sometimes, but having worked on Phalanger (PHP compiler for .NET) for some time, I have to say that doing eval in a language compiled to standard .NET code is totaly crazy.

Once again I have to strongly take issue with this.

I may misunderstand the subtle differences that make an 'eval' function: string -> Expr<'a> acceptable and a string -> ( () -> 'a ) not, but I see these as two small pieces of a fully featured scripting API.

Surely 'doing eval' is simply compilation - we do it every day. The question is whether and when we will be able to use the compiler as a service and do incremental compilation.

Moreover, I believe that when using dynamic evaluation, not using a language and compiler with a state of the art static type system and world class theorem proving is negligent in the extreme.

The 'killer app' for FSharp dynamic evaluation is the hundreds of thousands of spreadsheets that run this world's economy (quite poorly at the moment.) 10 years ago it was completely acceptable to run a $100 million dollar business on one large spreadsheet. The data, functions and formulas in this spreadsheet had no proper type system, no theorem proving, no pattern matching, no units of measure checking, no ability to incorporate unit tests. PEX can direcly analyse this compiled .NET IL to find errors and corner cases - thus producing robust, error-free code. What was acceptable 10 years ago is not acceptable now.

Creating rapid solutions in novel situations is why spreadsheets were so wildly successful in business. Using a dynamic language was, unfortunately, the only option available when these applications were created. This is no longer the case. FSharp has the strength, the speed and the elegance to replace dynamic languages in this role.

Question: Why is it so difficult to produce a simple calculator application in FSharp, when FSharp is the world's best calculator?

regards,

Danny

P.S. CodeDOM requires the correct version of FSharp to be installed on the users machine. This is a serious impediment to its use.

By on 3/5/2009 8:25 AM ()

Hi Danny,
sorry - I probably wasn't clear with in my last post. I'm still assuming that simple "eval" function isn't the same thing as "fully featured scripting API" (it certainly isn't!). The "eval" function working with quotations is useful for various meta-programming purposes, but I wouldn't really call this "dynamic".

The scripting API would be useful for exactly the kind of thing you describe. Of course, if we had full scripting API (something like library wrapper over F# interactive, which probably would be additional DLL in the F# distribution, or perhaps an additional thing you can install & distribute with your apps) it would be simple to implement "eval : string -> 'a". I just don't think of "eval" as the underlying thing for a complete scripting API - "eval" is in fact pretty bad scripting API :-).

I'd expect scripting API to be something like "FSharpInteractiveSession" type with member "SendCommand : string -> unit", "GetLastResult : unit -> obj", GetDeclaredValues, DeclareValue and things like that. That's probably the source of confusion here! And I certainly agree that this would be very valuable thing to have in F#.

I think the confusion is that standard "eval" functions in langauges are PHP look more like a hack than like a decent scripting API (which is something that would be very useful for F#).

Tomas

By on 3/5/2009 8:42 AM ()

It is said that F# is a dynamic language that is why I asked about Eval. Anyway it is good to have a functional language integrated in .NET Framework, for things like math calculations or so and then integrate this code in C#.

Thanks.

By on 3/4/2009 6:09 AM ()

Hi,

I would have to strongly disagree that distributing the FSharp compiler would be weird. Having a supported scripting API is one of the most requested features, both here on HubFS, and in enterprise environments.

Without a scripting API, FSharp would be limited to use by professional developers. Those developers would not be able to expose this wonderful language to Quantitative, Business and Financial Analysts, Math, Science and Engineering gradutes and anyone looking to explore and visualize data.

Currently developing a simple interactive graph plotting application is impossible with the FSharp language alone, requiring either an external DSL (either textual or visual) or hosting a scriptable language (like IronPython or Boo.)

This embodies the same schism that made working with Excel so bifurcated. Interactive development was done in VBA / R / Matlab by analysts. When this grew to be tangled and unmanagable the C++ team would decipher and rewrite. Having the domain experts and the professional developers speak different languages belongs to the past. FSharp's concision and expressiveness is a key to healing this divide. FSI brings us within touching distance of this goal - but not quite there.

I hope very much that the FSharp team have this as one of their highest priorities - I know for a fact they would be strongly supported both by enterprise and academia.

regards,

Danny

P.S: I also hope that the decision to leave the FSharp compiler out of .NET 4 is not final. Only this step would truely make FSharp a first-class language for the .NET platform.

By on 3/4/2009 6:58 AM ()

Hi,

>> Well, I guess static typing and compilation are incompatible with dynamic evaluation.

This isn't necessarily true. It is perfectly fine to dynamically evaluate quoted F# expressions and this can be done in a type-safe way. If we work with the type Expr<'T> representing a parsed expression, then we can have a function eval : Expr<'T> -> 'T which evaluates the expression (and that's partly what the LINQ evaluation I mentioned already does for <i>some <i>F# expressions, but not for all because LINQ expression trees are limited): <code lang=fsharp> let expr = <@ 1 + 2 @> // : Expr<int> let n = eval expr </code> So, I'm not saying it's not possible - I think it's perfectly possible, but it's just not implemented (probably because there were only a few requests for this and there is no really compeling "killer app" scenario where it would be needed). You'd also need some way to parse the string if you want "classical" eval function, but that can be done as well. >> Having a supported scripting API is one of the most requested features, both here on HubFS, and in enterprise environments. I definitely agree with that! But I think that from the F# perspective, this is something completely different than having "eval" function. I think of F# scripting environment as an "invisible F# interactive window" with some reasonable interface, so that you can control it programatically (define values, read values, etc...). This would be (I believe) much more suitable for allowing F# as a scripting langauge in enterprise applications. Implementing something like this with (probably) partly limited "eval" function is too much work (if it would be even possible with simple "eval"-like function), so having scripting API is (for me) a completely different issue, though I can see the point that it's related.

By on 3/4/2009 7:17 AM ()

It is still unclear why all these efforts to create a new functional and "dynamic" language(F#) when there is an implementation for .NET platform of such a language(IronPython).

By on 3/4/2009 7:59 AM ()

Hi,
well, I think the understanding that F# is a "new functional and dynamic language" is wrong. It is primarilly a functional and statically-typed (not an opposite to 'dynamic', but an opposit to 'dynamically typed'). The functional features of F# go much beyond what's available in Python, because F# is primarilly functional. The background of Python is I guess more something like a scripting language. Also, the statical typing gives you much more compile-time guarantees (which is a trend on the .NET plafrom in general - see for example the addition of contracts) and it gives better performance than Python.

This all makes F# (in my opinion) better for high-performance scientific applications and that's (I believe) the motivation for the efforts behind F#. I think the following announcement makes this clear: [link:blogs.msdn.com]

The interactive features of F# are important for this kind of development. The fact that F# looks like an attractive "dynamic scripting" language is for me a bonus point, but it's definitely an interesting possibility.

By on 3/4/2009 8:14 AM ()

Thanks for the explanations Tomas. It is very important to understand the purposes of a programming language, before starting to work with it. At least for me.

By on 3/4/2009 8:45 AM ()

Hi,
I think the following two links to content related to the book about F# I'm working on could help with understanding the general goal of F# and functional programming:

The first link is more technical and it should cover the F# programming style. The chapter 1 from the book also covers motivation for F# and functional programming in general (which could help for example when comparing goals of the F# language with IronPython and others)

By on 3/4/2009 9:03 AM ()

Hi,
it depends on the definition of "dynamic language". F# certainly allows you to do many dynamic things. I wrote a blog post about that some time ago: [link:tomasp.net]

Another dynamic aspect of F# is the "F# interactive" window in Visual Studio that allows you to use the REPL-style of interactive development (just like in dynamic & (originally) interpreted languages). However, F# is still in many ways static - it is statically typed and compiled to efficient .NET code (compared to for example IronPython).

By on 3/4/2009 6:18 AM ()

Well, I guess static typing and compilation are incompatible with dynamic evaluation. So no implementation of Eval is possible for F#. Thanks for the references.

By on 3/4/2009 6:57 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper