List with numbers #18

New Issue

Ghost · 2025-02-07T18:04:51Z

Ghost commented

2025-02-07 18:04:51 +00:00

Hi James!

Thank you for tricu!
It helps me a lot with getting familiar with triage calculus!

A list containing only numbers is not decoded correctly:

tricu < [ (1) (2) ]
tricu > ""

But this works:

tricu < [ (1) (2) ("e") ]
tricu > [1, 2, "e"]

Hi James! Thank you for tricu! It helps me a lot with getting familiar with triage calculus! A list containing only numbers is not decoded correctly: ```haskell tricu < [ (1) (2) ] tricu > "" ``` But this works: ```haskell tricu < [ (1) (2) ("e") ] tricu > [1, 2, "e"] ```

James commented

2025-02-07 18:24:19 +00:00

Hey @vincent , thanks for opening this! I'm quite early in development here so many features aren't properly documented.

You can work around this using the !decode command in the REPL for now which disables decoding entirely. This allows you to see the full Tree forms of your outputs.

The reason this happens is because strings are encoded as lists of numbers, so when the decoder function encounters [ (1) (2) ] , it believes that the value is a string containing the ASCII characters mapped to 1 and 2. The decoding function was a rushed implementation and can handle these situations much more intelligently, so I'll leave this issue open until I am able to make some changes so that it handles this better.

Hey @vincent , thanks for opening this! I'm quite early in development here so many features aren't properly documented. You can work around this using the `!decode` command in the REPL for now which disables decoding entirely. This allows you to see the full Tree forms of your outputs. The reason this happens is because strings are encoded as lists of numbers, so when the decoder function encounters [ (1) (2) ] , it believes that the value is a string containing the ASCII characters mapped to `1` and `2`. The [decoding function was a rushed implementation and can handle these situations much more intelligently]([url](https://git.eversole.co/James/tricu/src/branch/main/src/Research.hs#L163)), so I'll leave this issue open until I am able to make some changes so that it handles this better.

James self-assigned this 2025-02-07 18:24:47 +00:00

James added the

bug

label 2025-02-07 18:24:50 +00:00

James referenced this issue

2025-02-07 19:27:21 +00:00

Provided binaries are linked to glibc nix #20

James commented

2025-02-07 21:25:09 +00:00

Thank you @vincent for that additional feedback regarding the binaries; they're meant to be statically linked. I have some test builds running and if everything pans out, I'll update my pipelines here so that the next release works properly. Until then, I'll hold off on distributing further binaries as they're not going to be useful to anyone else. I'm tracking this in #20 and will tag you there when that is resolved.

As for the issue in this ticket, it's resolved in commit e6e18239a7 available now on main.

tricu < [(1) (2) (99) (300) (35)]
tricu > [1, 2, 99, 300, 35]

Lists that only contain the numbers 9, 10, 13, and 32...126 will still decode as strings:

tricu < [(32) (33) (34) (35) (9) (10) (13)]
tricu > " !"#
"

This looks to be an improvement. Let me know if you have any thoughts on further improvements for this behavior.

That commit also replaces the !decode REPL command I just mentioned to you with !output so that you can choose from the different output formats already implemented for the -t flag on tricu eval.

I really appreciate you reporting these problems to me. If you run into any others or have suggestions, please feel free to open another issue!

Thank you @vincent for that additional feedback regarding the binaries; they're meant to be statically linked. I have some test builds running and if everything pans out, I'll update my pipelines here so that the next release works properly. Until then, I'll hold off on distributing further binaries as they're not going to be useful to anyone else. I'm tracking this in #20 and will tag you there when that is resolved. As for the issue in this ticket, it's resolved in commit e6e18239a7 available now on main. ```haskell tricu < [(1) (2) (99) (300) (35)] tricu > [1, 2, 99, 300, 35] ``` Lists that only contain the numbers `9`, `10`, `13`, and `32...126` will still decode as strings: ```haskell tricu < [(32) (33) (34) (35) (9) (10) (13)] tricu > " !"# " ``` This looks to be an improvement. Let me know if you have any thoughts on further improvements for this behavior. That commit also replaces the `!decode` REPL command I just mentioned to you with `!output` so that you can choose from the different output formats already implemented for the `-t` flag on `tricu eval`. I really appreciate you reporting these problems to me. If you run into any others or have suggestions, please feel free to open another issue!

James closed this issue

2025-02-07 21:25:09 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: James/tricu#18