Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Verse Programming Language [pdf]

simon.peytonjones.org

Post reply on HN
Print view View original

191–200 of 387 posts

Re: The Verse Programming Language [pdf]

#191

Post by cryptonector »

rkrzr wrote: post #26

This looks incredibly ambitious: - There are no booleans in the language! Conditionals can still succeed or fail, but failure is defined as returning zero values and success is defined as returning one or more values. - Verse uses a so-called 'lenient' evaluation strategy which is neither strict nor lazy, but somewhere in-between ("Everything is eventually evaluated, but only when it is ready") - an expression does n…

Icon had (has!) "failure is falsity" / "value production is truth", and pervasive generators / backtracking. In Icon a function ("procedure") either: fails, returns a value, or suspends (yields) a value.

jq is very much like this too, as it has pervasive generators and backtracking, but unlike Icon jq does not distinguish between "returning" a value vs. "suspending" (yielding) a value.

The jq way kinda means you have to have booleans, and so jq does.

I'm suspicious of the no-booleans approach. After all, one could also have no integers (the Lambda Calculus doesn't have integers, having only function values!). Boolean values are just useful to have, and being able to obtain boolean values from predicates is useful too. One could do the Icon/Verse thing of failure is false / anything is true, but provide an adapter function that produces actual boolean values for when you need them.

Re: The Verse Programming Language [pdf]

#193

Post by Throwaway23459 »

justinhj wrote: post #189
Throwaway23459 wrote: post #170

Earlier quoted context omitted.

Has it got currying? Partially applied functions passed around in folds and traverses are horribly difficult to read for beginners. Example: an Advent of Code solution posted in r/haskell for Day 10 this year, tell me how long it takes you to understand the function cycleStrengths. signalStrength cycle x = cycle \* x cycleGaps = [19, 40, 40, 40, 40, 40] cycleStrengths = foldr a (const []) cycleGaps . (\x -> (1, x)) w…

That kind of code is sometimes easier to write than read… you build it up incrementally. On the other hand it’s easy to refactor this to make it readable. Is Haskell supposed to be an easy language for beginners? Is Verse? Not every language should be.

> [Paraphrasing] Is Verse supposed to be an easy language for beginners ?

Yes! Well that was the point of my comment. Maybe you have a different interpretation of 'Learnable as a first language' from the article, which is fine, not interested in arguing about that.

Re: The Verse Programming Language [pdf]

#194

Post by cryptonector »

mncharity wrote: post #84
thelazydogsback wrote: post #31

Some of this reminds of me a combination Icon and Mozart. (And happened to just come across my old Icon book a few days ago.) Maybe the backtracking concepts are "too built in?" - e.g., (1|2) is not a first-class/reified "amb" object, right? - so if I want to introduce a different search than depth-first backtracking (breadth, dependency-directed), etc., I couldn't directly. Seems like there could be some confusion b…

Can anyone speak to this for Icon? For context, Prolog had a culture of "the built-in search is less than wonderful... but good for crafting a problem-appropriate search". II(fuzzily)RC, Mozart/Oz decoupled nondeterministic code (explicit amb, spelled "dis") specification from search, and allowed managing search over nested spaces of unification constraints and threads. With (very fuzzy) less use of backtrack-driven…

In Icon a function ("procedure") can: fail, return a value, or "suspend" (yield) a value (and then again and again). The difference between returning and suspending being that a generator that returns cannot be resumed again. That difference was needed (IIRC) because the alternative would be to end the generator with failure, which could be confused with failure in a boolean sense. jq gets this better by saying that a function can produce zero, one, or more values (just like Verse), but unlike Verse, jq does have booleans.

I prefer the jq approach to the Icon approach, which I think means I am suspicious of this aspect of Verse :)

Also, boolean values are inherently useful, and while checking that an expression is empty or not is a boolean predicate, it should be a predicate that produces a boolean value. Otherwise if we have no boolean values then we shouldn't have integer values either and just go back to the Lambda Calculus!

Re: The Verse Programming Language [pdf]

#195

Post by lelanthran »

galaxyLogic wrote: post #76
rkrzr wrote: post #26

This looks incredibly ambitious: - There are no booleans in the language! Conditionals can still succeed or fail, but failure is defined as returning zero values and success is defined as returning one or more values. - Verse uses a so-called 'lenient' evaluation strategy which is neither strict nor lazy, but somewhere in-between ("Everything is eventually evaluated, but only when it is ready") - an expression does n…

> sequence of zero or more values You can try this type of programming at home, say in JavaScript Make any result or argument be an Array. The problem with nulls goes away because "not there" is represented simply by an empty Array (a.k.a "sequence"). And you will not get null-errors because you can write: newValue = someValue.filter(...) . map(...) ; You don't need to test whether filter() returns an empty array or…

> I sometimes wonder why I don't use this pattern more often.

Because while handy, it's not universally applicable (just like everything else :-))

I (C programmer, mostly) use sequences more often than you'd expect for parameters[1], but that does not mean that it makes sense to always return sequences.

In a lot of cases, sure, a function should return a sequence of values. In many other cases, it makes no sense - `if (canProceed(x,y,z))` reads more sensibly than `if (canProceed(x, y, z)[0]`.

[1] My string functions mostly lend themselves well to unlimited number of parameters. For example concatenation takes unlimited parameters and concats all of them, which it returns. Same with substring searching - take a source string and an unlimited number of substrings to find.

Re: The Verse Programming Language [pdf]

#197

Post by bodhiandphysics »

yewenjie wrote: post #192

Is the choice operator somehow analogous to OR? If not, why not just choose any other syntax than `|`?

It is or... i.e x := (3 | 4) means x is either 3 or 4. The ; seems to be basically be an and. The evaluation finds an assignment of the values such that the world is true. For instance x:= (3 |4); (x % 2 = 1); x evaluates to 4. Type checking and evaluation seem to be the same thing... so x:= (int | string) x = ("hello" | 4.3); x might evaluate to "hello"

Re: The Verse Programming Language [pdf]

#198

Post by cryptonector »

FullyFunctional wrote: post #140
zozbot234 wrote: post #118

Earlier quoted context omitted.

> This all looks very mind-bending to me (in a good way). Perhaps Verse will one day be as influential for PL design as Haskell has been. I'm not convinced. Making non-determinism a first-class feature in the language might be good if you simply care about logical specifications that might enable you to prove something correct, but a real-world program implementation has to make heuristic choices for efficiency as to…

But it's very much not non-deterministic. It's a deterministic choice. You can give it an exact semantics.

Correct, but "non-determinism" is a misnomer used in programming language theory to refer to generators and pervasive backtracking. Prolog, Icon, jq, etc. -- all fully deterministic, but known as non-deterministic owing to the pervasive generators and backtracking.

Re: The Verse Programming Language [pdf]

#199

Post by felixyz »

8f2ab37a-ed6c wrote: post #6

It's riveting to follow the evolution of Tim Sweeney's dream of a more Haskell-like programming language for games since his 2005 talk: https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...

When did the L in FLP enter into the vision? I heard SPJ talk about the project a couple of times in interviews, but don't recall him mentioning anything about Curry or logic programming. I'm thrilled they seem to be taking that path!
Post reply on HN