Is there something like find_consts but to search for ML constants in Isabelle?
For instance, I wish to find constants of this type: "term => cterm". Of course, "Thm.cterm_of" does the job, but it would be convenient to have this in general.
Related
I'm working on a programming language that is supposed to be easy, intuitive, and succinct (yeah, I know, I'm the first person to ever come up with that goal ;-) ).
One of the features that I am considering for simplifying the use of container types is to make the methods of the container's element type available on the container type itself, basically as a shortcut for invoking a map(...) method. The idea is that working with many elements should not be different from working with a single element: I can apply add(5) to a single number or to a whole list of numbers, and I shouldn't have to write slightly different code for the "one" versus the "many" scenario.
For example (Java pseudo-code):
import static java.math.BigInteger.*; // ZERO, ONE, ...
...
// NOTE: BigInteger has an add(BigInteger) method
Stream<BigInteger> numbers = Stream.of(ZERO, ONE, TWO, TEN);
Stream<BigInteger> one2Three11 = numbers.add(ONE); // = 1, 2, 3, 11
// this would be equivalent to: numbers.map(ONE::add)
As far as I can tell, the concept would not only apply to "container" types (streams, lists, sets...), but more generally to all functor-like types that have a map method (e.g., optionals, state monads, etc.).
The implementation approach would probably be more along the lines of syntactic sugar offered by the compiler rather than by manipulating the actual types (Stream<BigInteger> obviously does not extend BigInteger, and even if it did the "map-add" method would have to return a Stream<BigInteger> instead of an Integer, which would be incompatible with most languages' inheritance rules).
I have two questions regarding such a proposed feature:
(1) What are the known caveats with offering such a feature? Method name collisions between the container type and the element type are one problem that comes to mind (e.g., when I call add on a List<BigInteger> do I want to add an element to the list or do I want to add a number to all elements of the list? The argument type should clarify this, but it's something that could get tricky)
(2) Are there any existing languages that offer such a feature, and if so, how is this implemented under the hood? I did some research, and while pretty much every modern language has something like a map operator, I could not find any languages where the one-versus-many distinction would be completely transparent (which leads me to believe that there is some technical difficulty that I'm overlooking here)
NOTE: I am looking at this in a purely functional context that does not support mutable data (not sure if that matters for answering these questions)
Do you come from an object-oriented background? That's my guess because you're thinking of map as a method belonging to each different "type" as opposed to thinking about various things that are of the type functor.
Compare how TypeScript would handle this if map were a property of each individual functor:
declare someOption: Option<number>
someOption.map(val => val * 2) // Option<number>
declare someEither: Either<string, number>
someEither.map(val => val * 2) // Either<string,number>
someEither.mapLeft(string => 'ERROR') // Either<'ERROR', number>
You could also create a constant representing each individual functor instance (option, array, identity, either, async/Promise/Task, etc.), where these constants have map as a method. Then have a standalone map method that takes one of those "functor constant"s, the mapping function, and the starting value, and returns the new wrapped value:
const option: Functor = {
map: <A, B>(f: (a:A) => B) => (o:Option<A>) => Option<B>
}
declare const someOption: Option<number>
map(option)(val => val * 2)(someOption) // Option<number>
declare const either: Functor = {
map: <E, A, B>(f: (a:A) => B) => (e:Either<E, A>) => Either<E, B>
}
declare const either: Either<string,number>
map(either)(val => val * 2)(someEither)
Essentially, you have a functor "map" that uses the first parameter to identify which type you're going to be mapping, and then you pass in the data and the mapping function.
However, with proper functional languages like Haskell, you don't have to pass in that "functor constant" because the language will apply it for you. Haskell does this. I'm not fluent enough in Haskell to write you the examples, unfortunately. But that's a really nice benefit that means even less boilerplate. It also allows you to write a lot of your code in what is "point free" style, so refactoring becomes much easier if you make your language so you don't have to manually specify the type being used in order to take advantage of map/chain/bind/etc.
Consider you initially write your code that makes a bunch of API calls over HTTP. So you use a hypothetical async monad. If your language is smart enough to know which type is being used, you could have some code like
import { map as asyncMap }
declare const apiCall: Async<number>
asyncMap(n => n*2)(apiCall) // Async<number>
Now you change your API so it's reading a file and you make it synchronous instead:
import { map as syncMap }
declare const apiCall: Sync<number>
syncMap(n => n*2)(apiCall)
Look how you have to change multiple pieces of the code. Now imagine you have hundreds of files and tens of thousands of lines of code.
With a point-free style, you could do
import { map } from 'functor'
declare const apiCall: Async<number>
map(n => n*2)(apiCall)
and refactor to
import { map } from 'functor'
declare const apiCall: Sync<number>
map(n => n*2)(apiCall)
If you had a centralized location of your API calls, that would be the only place you're changing anything. Everything else is smart enough to recognize which functor you're using and apply map correctly.
As far as your concerns about name collisions, that's a concern that will exist no matter your language or design. But in functional programming, add would be a combinator that is your mapping function passed into your fmap (Haskell term) / map(lots of imperative/OO languages' term). The function you use to add a new element to the tail end of an array/list might be called snoc ("cons" from "construct" spelled backwards, where cons prepends an element to your array; snoc appends). You could also call it push or append.
As far as your one-vs-many issue, these are not the same type. One is a list/array type, and the other is an identity type. The underlying code treating them would be different as they are different functors (one contains a single element, while one contains multiple elements.
I suppose you could create a language that disallows single elements by automatically wrapping them as a single-element lists and then just uses the list map. But this seems like a lot of work to make two things that are very different look the same.
Instead, the approach where you wrap single elements to be identity and multiple elements to be a list/array, and then array and identity have their own under-the-hood handlers for the functor method map probably would be better.
I'm trying to port a library from JS, and I've gotten to a function that can either take a string or a list of strings. If given a string, it'll split it into a list of strings and then continue as if it had been passed that in the first place.
I can sort of do it by defining my own type, but it makes the API ugly and require a custom Type prefix your data.
Here's what I've got:
type DocumentBody = Raw String | Words List String
tokenize: DocumentBody -> List String
tokenize s =
case s of
Raw str_body -> String.split " " str_body |> (List.map String.toLower)
Words list_body -> List.map String.toLower list_body
-- Tests
tests =
suite "Tokenizer"
[ test "simple" <| assertEqual ["this", "is", "a", "simple", "string"]
<| tokenize (Raw "this is a simple string")
, test "downcasing tokens: string" <| assertEqual ["foo", "bar"]
<| tokenize (Raw "FOO BAR")
, test "downcasing tokens: list of str" <| assertEqual ["foo", "bar"]
<| tokenize (Words ["Foo", "BAR"])
]
Ultimately, I don't think that the port should support this kind of behavior, but how do you pattern match on just the enumerations of the type instead of needing the prefix Raw or Words in my example?
No, you cannot overload functions in elm the same way you can in other languages. Each function has a single signature. If you want a function to accept a parameter that can be of many types, your solution using a union type works just fine.
You say it makes the API ugly. I wouldn't call it ugly. Perhaps the syntax of the type declaration or case statements is unappealing but I say, give it time. It will grow on you. There's a lot of power and safety there. You're not letting the code make any assumptions, you are forced to handle every scenario, and it's one of the strengths of working in a language like elm.
Your pattern matching code is appropriate. You cannot shorten it beyond that.
At the same time, I can understand the pain of rewriting a javascript library and trying to communicate over ports from raw javascript. You're rewriting things in a much stricter language, and you won't be able to duplicate function signatures that in javascript, accepted anything and everything. But again, that's a strength of elm, not a weakness. Use the opportunity to tighten up the API and remove ambiguity.
When it comes to your specific example, to me it feels like there are a few possible alternatives beyond your solution. I'd argue that the tokenize function is promising too much to begin with; it's too ambiguous. When writing code in functional languages, I prefer to keep things small and composable. To me, it should really be two separate functions, each with a single, specific purpose.
I am implementing a simple C-like language in OCaml and, as usual, AST is my intermediate code representation. As I will be doing quite some traversals on the tree, I wanted to implement
a visitor pattern to ease the pain. My AST currently follows the semantics of the language:
type expr = Plus of string*expr*expr | Int of int | ...
type command = While of boolexpr*block | Assign of ...
type block = Commands of command list
...
The problem is now that nodes in a tree are of different type. Ideally, I would pass to the
visiting procedure a single function handling a node; the procedure would switch on type of the node and do the work accordingly. Now, I have to pass a function for each node type, which does not seem like a best solution.
It seems to me that I can (1) really go with this approach or (2) have just a single type above. What is the usual way to approach this? Maybe use OO?
Nobody uses the visitor pattern in functional languages -- and that's a good thing. With pattern matching, you can fortunately implement the same logic much more easily and directly just using (mutually) recursive functions.
For example, assume you wanted to write a simple interpreter for your AST:
let rec run_expr = function
| Plus(_, e1, e2) -> run_expr e1 + run_expr e2
| Int(i) -> i
| ...
and run_command = function
| While(e, b) as c -> if run_expr e <> 0 then (run_block b; run_command c)
| Assign ...
and run_block = function
| Commands(cs) = List.iter run_command cs
The visitor pattern will typically only complicate this, especially when the result types are heterogeneous, like here.
It is indeed possible to define a class with one visiting method per type of the AST (which by default does nothing) and have your visiting functions taking an instance of this class as a parameter. In fact, such a mechanism is used in the OCaml world, albeit not that often.
In particular, the CIL library has a visitor class
(see https://github.com/kerneis/cil/blob/develop/src/cil.mli#L1816 for the interface). Note that CIL's visitors are inherently imperative (transformations are done in place). It is however perfectly possible to define visitors that maps an AST into another one, such as in Frama-C, which is based on CIL and offer in-place and copy visitor. Finally Cαml, an AST generator meant to easily take care of bound variables, generate map and fold visitors together with the datatypes.
If you have to write many different recursive operations over a set of mutually recursive datatypes (such as an AST) then you can use open recursion (in the form of classes) to encode the traversal and save yourself some boiler plate.
There is an example of such a visitor class in Real World OCaml.
The Visitor pattern (and all pattern related to reusable software) has to do with reusability in an inclusion polymorphism context (subtypes and inheritance).
Composite explains a solution in which you can add a new subtype to an existing one without modifying the latter one code.
Visitor explains a solution in which you can add a new function to an existing type (and to all of its subtypes) without modifying the type code.
These solutions belong to object-oriented programming and require message sending (method invocation) with dynamic binding.
You can do this in Ocaml is you use the "O" (the Object layer), with some limitation coming with the advantage of having strong typing.
In OCaml Having a set of related types, deciding whether you will use a class hierarchy and message sending or, as suggested by andreas, a concrete (algebraic) type together with pattern matching and simple function call, is a hard question.
Concrete types are not equivalent. If you choose the latter, you will be unable to define a new node in your AST after your node type will be defined and compiled. Once said that a A is either a A1 or a A2, your cannot say later on that there are also some A3, without modifying the source code.
In your case, if you want to implement a visitor, replace your EXPR concrete type by a class and its subclasses and your functions by methods (which are also functions by the way). Dynamic binding will then do the job.
Is there a language, which is:
1) functional
2) has type inference
3) has currying
4) and has types as first-class values
also would like to compile from it to JVM and/or CLR
F# is functional and has type inference, currying and types as first-class values in the sense that you can dissect types at run-time via reflection. It compiles to the CLR and works well on Mono.
EXAMPLE: Taken from my (non-free) article Structural Typing in the F#.NET Journal:
The following createType function creates a new .NET assembly, new module and new public class type of the given name:
> let createType typeName =
let name = System.Reflection.AssemblyName(Name="tmpAssembly")
let run = System.Reflection.Emit.AssemblyBuilderAccess.Run
let builder = System.Threading.Thread.GetDomain().DefineDynamicAssembly(name, run)
let mdl = builder.DefineDynamicModule "tmpModule"
let attrs = TypeAttributes.Public ||| TypeAttributes.Class
mdl.DefineType(typeName, attrs);;
val createType : string -> TypeBuilder
I just started learning it but Coq might work for you.
It's quite possible to have a function which takes in a type (yes a raw type, not an instance of that type) and return another type (again, just the type, not an instance). If you're at all interested in formal verification of programs it's worth a look.
It also has the nice little benefit of being able to convert it's code to Haskell/OCaml/Scheme so that you can use their IO/Libraries since Coq tends lacks them.
It has type inference and currying but the type inference isn't perfect as the language's type system is well beyond (and more expressive than) a standard Milner-Hindley type system.
Take a look at Scala, it works on both JVM and .NET. Here is some features including what you seek - http://www.scala-lang.org/node/104, look at "Scala is functional" section, "Local Type Inference", "Currying" and "Predefined function classOf" articles, also it has top type Any, pattern matching for values and types, reflect package.
First start from wikipedia type interference. Answer for this question seems to be Haskell or OCaml.
Is their an equivalent to C#'s Expression API in scala?
For example, I would like to have a lambda like this:
(Foo) => Foo.bar
and be able to access "bar" in the function it is passed to.
This is not supported by Scala. ScalaQL: Language-Integrated Database Queries
for Scala describes a LINQ-like functionality in Scala:
While it is possible for Microsoft to
simply extend their language with this
particular feature, lowly application
developers are not so fortunate. For
exam- ple, there is no way for anyone
(outside of Sun Microsystems) to
implement any form of LINQ within Java
because of the language modications
which would be required. We faced a
similar problem attempting to
implement LINQ in Scala.
Fortunately, Scala is actually
powerful enough in and of itself to
implement a form of LINQ even without
adding support for expression trees.
Through a combination of operator
overloading, implicit conversions, and
controlled call- by-name semantics, we
have been able to achieve the same
eect without making any changes to
the language itself.
There is an experimental scala.reflect.Code.lift which might be of interest, but the short answer is no, Scala does not have access to the AST in any form (expression trees are a subset of C#'s AST).
It's not quite clear to me what you want. If you want a function that returns a getter for a field, you can do that quite easily:
class Holder(var s: String) { }
class StringSaver(f: Holder => (() => String), h: Holder) {
val getter = f(h)
def lookAtString = getter()
}
val held = new Holder("Hello")
val ss = new StringSaver((h: Holder) => (h.s _) , held)
println(ss.lookAtString)
held.s = "Bye now"
println(ss.lookAtString)
The key is to turn the getter h.s into a function via (h.s _).
No, to the best of my knowledge.