too few args · bugs · Zulip Chat Archive

Stream: bugs

Topic: too few args

Anthony Bullard (Jan 17 2025 at 22:44):

I anyone else seeing TOO FEW ARGS reports when using pipes on main:HEAD(latest latest)?

Anthony Bullard (Jan 17 2025 at 22:45):

I have to imagine we have CI tests that run Builtins or some other tests for stuff like that...

Sam Mohr (Jan 17 2025 at 22:46):

Let's see...

Anthony Bullard (Jan 17 2025 at 22:46):

I'm on:

❯ roc --version
roc built from commit f3376af9c1, committed at 2025-01-17 15:29:09 UTC

Anthony Bullard (Jan 17 2025 at 22:46):

Any pipes and I get TOO FEW ARGS

Sam Mohr (Jan 17 2025 at 22:53):

» x = |y| y + 123


<function> : Num a -> Num a
»

Enter an expression to evaluate, or a definition (like x = 1) to use later.

  - ctrl-v + ctrl-j makes a newline
  - :q quits
  - :help shows this text again

» 123 |> x

246 : Num *
»

Anthony Bullard (Jan 17 2025 at 23:04):

I think it's only multiline pipes

Anthony Bullard (Jan 17 2025 at 23:04):

The repl is busted as well

Anthony Bullard (Jan 17 2025 at 23:04):

Can someone with perms move this to a thread in #bugs ?

Notification Bot (Jan 17 2025 at 23:33):

9 messages were moved here from #ideas > ? for mapping Result Err values by Luke Boswell.

Anthony Bullard (Jan 17 2025 at 23:43):

Thanks Luke!

Anton (Jan 18 2025 at 10:22):

Can you share some reproductions @Anthony Bullard

Anthony Bullard (Jan 18 2025 at 11:22):

Sure

Anthony Bullard (Jan 18 2025 at 11:31):

Well...Maybe not...

Anthony Bullard (Jan 18 2025 at 11:38):

Now I'm pissed off.

Anthony Bullard (Jan 18 2025 at 11:41):

@Anton Can't reproduce now because why would good things happen, but the REPL still does not allow you to create multiline expressions with ctrl-j or ctrl-v

Anthony Bullard (Jan 18 2025 at 12:29):

@Anton Got it

module [run!]

import pf.Stdout
import pf.Path exposing [Path]

raw_exercises! : Path => List Path
raw_exercises! = |path|
    Path.list_dir!(path)
    ?? []

exercise_numbers : List Path -> List U32
exercise_numbers = |paths|
    paths
    |> List.keep_if(|p| Str.starts_with(Path.display(p), "exercise_") && Str.ends_with(Path.display(p), ".roc"))
    |> List.keep_oks(
        |p|
            p_str = Path.display(p)
            p_parts = Str.split_on(p_str, "_")
            when p_parts is
                [_, number, ..] -> Ok(Str.to_u32(number)?)
                _ -> Err(InvalidEx),
    )

run! : Path => Result {} _
run! = |path|
    ex = raw_exercises!(path) |> exercise_numbers |> List.sort_asc()
    num = [] |> List.first()?
    Stdout.line!("Checking your solutions for exercise ${Num.to_str(num)}...")

Anthony Bullard (Jan 18 2025 at 12:30):

The minimal repro would be

module [something!]

import pf.Stdout

something! = |_|
    ex = ["hello"] |> List.first()?
    Stdout.line!(ex)

Anthony Bullard (Jan 18 2025 at 12:30):

So pipe + PNC + try suffix?

Anton (Jan 18 2025 at 12:54):

I made #7530 for this.

Anton (Jan 18 2025 at 12:55):

If we look at the desugared version we'll probably be able to make sense of this.

Anton (Jan 18 2025 at 12:55):

@Sam Mohr may also have an idea what's going on

Sam Mohr (Jan 18 2025 at 12:57):

https://github.com/roc-lang/roc/blob/1e087b138d18f90daaf60b5eb71ed7afc3498064/crates/compiler/can/src/desugar.rs#L114

Sam Mohr (Jan 18 2025 at 12:58):

The desugaring should be working, but a well placed dbg! might be useful

Anton (Jan 20 2025 at 10:25):

I'm going to look at this issue

Anton (Jan 20 2025 at 15:01):

Screenshot from 2025-01-20 15-53-17.png
This is the code after desugaring. It's obvious what is going wrong but I'm not sure how things should be changed :thinking:

Anthony Bullard (Jan 20 2025 at 15:15):

Desugar to a Defs then break up the pipe and pass the new def explicitly?

Anton (Jan 20 2025 at 18:50):

@Sam Mohr, can you weigh in as well here?

Anthony Bullard (Jan 20 2025 at 18:59):

He'll probably wake up in 3 hours :tears:

Sam Mohr (Jan 20 2025 at 20:32):

Anthony is on the money IMO

Sam Mohr (Jan 20 2025 at 20:33):

We shouldn't worry about performance since we are removing pizza from the menu

Sam Mohr (Jan 20 2025 at 20:33):

Once it's gone, we can figure out how to make this work better

Anton (Jan 22 2025 at 14:26):

Desugar to a Defs then break up the pipe and pass the new def explicitly?

Should I do this for every use of the pizza operator (here in the code)?

Anthony Bullard (Jan 22 2025 at 14:45):

That makes sense to me. Easier to reason about

Sam Mohr (Jan 25 2025 at 13:18):

Just to note, this is incorrect code, even if the error message is misleading:

module [something]

something = |_|
    ["hello"] |> List.first()?

Sam Mohr (Jan 25 2025 at 13:18):

The ? means we're trying to return Str as the final expression instead of Result Str _

Sam Mohr (Jan 25 2025 at 13:18):

Hopefully, my attempt to fix things will alleviate that anyway

Sam Mohr (Jan 25 2025 at 13:46):

Fixed in https://github.com/roc-lang/roc/pull/7548

Sam Mohr (Jan 25 2025 at 13:46):

module [something]

something = |_|
    ["hello"] |> List.first()?

> cargo run --bin roc -- check test2.roc
...

── TYPE MISMATCH in ../test2.roc ───────────────────────────────────────────────

This returns something that's incompatible with the return type of the
enclosing function:

4│      ["hello"] |> List.first()?
        ^^^^^^^^^^^^^^^^^^^^^^^^^

This returns an Err of type:

    [Err [ListWasEmpty]]

But I expected the function to have return type:

    Str

────────────────────────────────────────────────────────────────────────────────

1 error and 0 warnings found in 121 ms.

Anton (Jan 25 2025 at 14:24):

incompatible with the return type of the enclosing function

I don't understand, the type of something is not specified, so how does it know the return type should be a Str?

Sam Mohr (Jan 25 2025 at 14:25):

Because it's operating on a List Str

Sam Mohr (Jan 25 2025 at 14:25):

And the ? can AST node has special Result type checking I added

Sam Mohr (Jan 25 2025 at 14:28):

We could make the error message better when ? is used on the return value of a function, I don't think that's ever valid

Sam Mohr (Jan 25 2025 at 14:28):

But this message is accurate for now

Sam Mohr (Jan 25 2025 at 14:29):

So I don't think we should block release on such an error message

Sam Mohr (Jan 25 2025 at 14:29):

Assuming we merge this PR

Anton (Jan 25 2025 at 14:39):

In this case the ? is not used on the return value:

app [main!] {
    pf: platform "https://github.com/roc-lang/basic-cli/releases/download/0.19.0/bi5zubJ-_Hva9vxxPq4kNx4WHX6oFs8OP>
}

import pf.Stdout

main! = |_args|
    Stdout.line!("")

find : List U64, U64 -> Result U64 [ValueWasNotFound (List U64) U64]
find = |array, value|
    binary_search = |min_index, max_index|
        middle_index = (min_index + max_index) // 2
        middle_value = array |> List.get(middle_index)?
        if middle_value == value then
            Ok(middle_index)
        else if min_index == max_index then
            Err(ValueWasNotFound(array, value))
        else if middle_value < value then
            Ok(binary_search((middle_index + 1), max_index)?)
        else
            Ok(binary_search(min_index, (middle_index - 1))?)

    binary_search(0, List.len(array))
    |> Result.on_err(|_| Err(ValueWasNotFound(array, value)))

# finds a value in an array with one element
expect
    result = [6] |> find(6)
    result == Ok(0)

What's the problem here, is it just operator precedence?

Anthony Bullard (Jan 25 2025 at 14:39):

I approved the PR

Anton (Jan 25 2025 at 14:40):

The error is:

── TOO FEW ARGS in BinarySearch.roc ────────────────────────────────────────────

The get function expects 2 arguments, but it got only 1:

7│          middle_value = array |> List.get(middle_index)?
                                    ^^^^^^^^

Roc does not allow functions to be partially applied. Use a closure to
make partial application explicit.

────────────────────────────────────────────────────────────────────────────────

1 error and 0 warnings found in 30 ms

Anthony Bullard (Jan 25 2025 at 14:40):

Yes, precendence would be the issue

Anthony Bullard (Jan 25 2025 at 14:40):

a suffix would bind stronger than a infix

Anton (Jan 25 2025 at 14:42):

Hmm, in the case of

4│      ["hello"] |> List.first()?
        ^^^^^^^^^^^^^^^^^^^^^^^^^

It looks like |> is binding stronger

Sam Mohr (Jan 25 2025 at 14:46):

Anton said:

The error is:

── TOO FEW ARGS in BinarySearch.roc ────────────────────────────────────────────

The get function expects 2 arguments, but it got only 1:

7│          middle_value = array |> List.get(middle_index)?
                                    ^^^^^^^^

Roc does not allow functions to be partially applied. Use a closure to
make partial application explicit.

────────────────────────────────────────────────────────────────────────────────

1 error and 0 warnings found in 30 ms

Is this on my PR branch?