4 ms·

Text from the "10,000 Foot View" slide: -- Verse is a functional logic language (like Curry or Mercury). Verse is a declarative language: a variable names a

Text from the "10,000 Foot View" slide: -- Verse is a functional logic language (like Curry or Mercury). Verse is a declarative language: a variable names a single value, not a cell whose value changes over time. Verse is lenient but not strict: Like strict:, everything gets evaluated in the end Like lazy: functions can be called before the argument has a value Verse has an unusual static type system: types are firstclass values. Verse has an effect system, rather than using monads.

mncharity 4y ago
I'll add text from the "Take-aways" slide: -- Verse is extremely ambitious Kick functional logic programming out the lab and into the mainstream Stretches from end users to professional developers Transactional memory at scale Very strong stability guarantees A radical new approach to types [me: predicate functions] Verse is open Open spec, open-source compiler, published papers (I hope!) Before long: a conversation to which you can contribute
- deleted 4y ago
  [deleted]
baby 4y ago
> Types are firstclass values That sounds interesting to me. Part of why I don’t like GADTs in OCaml is that it feels like you’re trying to fit a programming language within the syntax of the type system.
cryptonector 4y ago
> Like strict:, everything gets evaluated in the end > Like lazy: functions can be called before the argument has a value FYI, jq is just like that. In jq in `def f(g): ...;` `g` is a function value that will be applied to some input of `f`'s choice, and `g` is not evaluated unless `f` invokes it. The actual argument to `f` will be an expression which is wrapped in a closure named `g` while `f` is executing. Lazy evaluation really is just hidden closures. Lazy evaluation raises questions like: How obvious shall the syntax make it that you will be passing a closure instead of a value? Closures of dynamic or indefinite extent? Can you choose which? How intrusive in the syntax is that choice? Does the use of lazy vs. strict infect callees? I.e., if I define a function `f` of one argument of type `T`, must it be able to take an argument that is a closure that produces values of type `T`, or must that be declared separately? If the latter, does that mean I end up with two `f`s, one which takes a value of type `T` and one which takes a closure that produces (a) value(s) of type `T`? If so, does that happen automatically or must I request it? If the latter, what is the default, and what happens if some library I want to use one option doesn't provide it? Finding a happy medium with some flavor of lazy evaluation but also which doesn't make it hard to understand the performance considerations of it is just very hard.

mncharity 4y ago

I'll add text from the "Take-aways" slide: -- Verse is extremely ambitious Kick functional logic programming out the lab and into the mainstream Stretches from end users to professional developers Transactional memory at scale Very strong stability guarantees A radical new approach to types [me: predicate functions] Verse is open Open spec, open-source compiler, published papers (I hope!) Before long: a conversation to which you can contribute

deleted 4y ago
[deleted]

baby 4y ago

> Types are firstclass values That sounds interesting to me. Part of why I don’t like GADTs in OCaml is that it feels like you’re trying to fit a programming language within the syntax of the type system.

cryptonector 4y ago

> Like strict:, everything gets evaluated in the end > Like lazy: functions can be called before the argument has a value FYI, jq is just like that. In jq in `def f(g): ...;` `g` is a function value that will be applied to some input of `f`'s choice, and `g` is not evaluated unless `f` invokes it. The actual argument to `f` will be an expression which is wrapped in a closure named `g` while `f` is executing. Lazy evaluation really is just hidden closures. Lazy evaluation raises questions like: How obvious shall the syntax make it that you will be passing a closure instead of a value? Closures of dynamic or indefinite extent? Can you choose which? How intrusive in the syntax is that choice? Does the use of lazy vs. strict infect callees? I.e., if I define a function `f` of one argument of type `T`, must it be able to take an argument that is a closure that produces values of type `T`, or must that be declared separately? If the latter, does that mean I end up with two `f`s, one which takes a value of type `T` and one which takes a closure that produces (a) value(s) of type `T`? If so, does that happen automatically or must I request it? If the latter, what is the default, and what happens if some library I want to use one option doesn't provide it? Finding a happy medium with some flavor of lazy evaluation but also which doesn't make it hard to understand the performance considerations of it is just very hard.