!laJBzNwLcAOMAbAEeQ:matrix.org

k

665 Members
Discussion about the various k languages. For ngn/k dicussion, please see #ngnk:matrix.org16 Servers

Load older messages


SenderMessageTime
15 Apr 2024
@_discord_595317473247756288:t2bot.ioalexshroyer here's mine: https://github.com/hoosierEE/element/blob/main/src/misc/Parser.py 22:24:34
@ovf:beeper.comovf
In reply to @_discord_624974820840308737:t2bot.io
what is the result you are looking for? i.e. what's the "full ast" here
e.g. if your compose verb is ('), .(+-) should be (';+:;-) -- quite similar to the result of parse"+-"
22:24:37
@_discord_624974820840308737:t2bot.iocoltim ooh okay, thanks 22:32:01
@_discord_624974820840308737:t2bot.iocoltim one aside I have is that are parse trees useful without a fully functional eval? like ngn/k has parse trees but besides .generalList (which doesn't resolve variables and doesn't handle nested stuff), I don't think they are used for anything? 22:32:48
@_discord_870115701279584326:t2bot.iodiscodoug One nice thing about K2 is that errors didn’t unwind and instead left you in the interpreter state at the point of the error. While those errors meant you had to escape out of various layers it also made it easier to debug. 22:57:55
@_discord_870115701279584326:t2bot.iodiscodoug * One nice thing about K2 is that errors didn’t unwind and instead left you in the interpreter state at the point of the error. While that meant you had to escape out of various layers it also made it easier to debug. 22:58:17
@_discord_595317473247756288:t2bot.ioalexshroyer Is that recursive descent? 23:08:08
@dzaima:matrix.orgdzaima I think so 23:08:20
@dzaima:matrix.orgdzaima I didn't write it with any specific parsing method in mind, but it certainly does contain recursion for the various brackets 23:09:54
@_discord_595317473247756288:t2bot.ioalexshroyer Yeah I guess the different "precedence levels" aren't focused on operators but rather noun/verb/adverb, and of yeah - recur when you're inside parens. 23:12:11
@dzaima:matrix.orgdzaima (kinda based on my much less ugly APL parser but ended up rather different) 23:17:40
@_discord_595317473247756288:t2bot.ioalexshroyer nice to see another variation, thanks 23:23:50
@_discord_870115701279584326:t2bot.iodiscodoug There’s [this](https://dfns.dyalog.com/n_parse.htm) 23:27:31
16 Apr 2024
@semperos:matrix.fedibird.comsemperos In Goal, is there a way to invoke dyadic json to produce the JSON values true and false? 02:04:30
@anaseto:matrix.organaseto
In reply to @semperos:matrix.fedibird.com
In Goal, is there a way to invoke dyadic json to produce the JSON values true and false?
No, there isn't. Like in ngn/k, the type system doesn't have a boolean type: from the user perspective they're just integers, so there's no way to distinguish in a predictable way (even though there's an internal boolean flag for optimization purposes).
If you know enough about the data, you could maybe use some kind of string placeholder to represent true and false before converting to json, and then perform a substitution.
06:50:45
@_discord_870115701279584326:t2bot.iodiscodoug FWIW, my take is that json simply isn’t a serialization protocol. It’s for encoding data. In my user side json parser/serializer I use symbols for true, false and null and simply don’t attempt to serialize any other symbols. Bools get deserialized to these symbols as well with the understanding that the client will know how to handle the data. 08:00:48
@_discord_870115701279584326:t2bot.iodiscodoug @semperos - You could probably port my json parser to goal if you need this. 08:01:33
@_discord_870115701279584326:t2bot.iodiscodoug YAML attempts to be flexible enough to be used for arbitrary serialization but it’s also a PITA. I generally prefer to write native code if possible but if I needed this I’d probably look at using an ffi. 08:04:48
@_discord_870115701279584326:t2bot.iodiscodoug If I remember correctly IJ had a similar take on JSON. 08:22:12
@semperos:matrix.fedibird.comsemperos
In reply to @anaseto:matrix.org
No, there isn't. Like in ngn/k, the type system doesn't have a boolean type: from the user perspective they're just integers, so there's no way to distinguish in a predictable way (even though there's an internal boolean flag for optimization purposes).
If you know enough about the data, you could maybe use some kind of string placeholder to represent true and false before converting to json, and then perform a substitution.
Thanks for the reply! That's what I gathered from reading problems.md in your repo and looking at the testdata (which were very helpful). The string replacement approach makes sense. I may even see what it's like to extend Goal with something like a json.true and json.false values, since I have code that builds up JSON objects that represent queries for systems I don't control and would like to be able to produce those values in a first-class way.
13:25:47
@anaseto:matrix.organaseto
In reply to @semperos:matrix.fedibird.com
Thanks for the reply! That's what I gathered from reading problems.md in your repo and looking at the testdata (which were very helpful). The string replacement approach makes sense. I may even see what it's like to extend Goal with something like a json.true and json.false values, since I have code that builds up JSON objects that represent queries for systems I don't control and would like to be able to produce those values in a first-class way.
Yeah, you could define some JSONBool type for true and false implementing both the goal.Value interface and json.Marshaler, which would then work for marshalling in current json built-in (but for unmarshalling you would need to write a modified json builtin that handles true and false with your new types). Both json.true and json.false would be boxed values, so performance wouldn't be as good for large arrays of such json booleans (they would be stored in a generic array), but if it's just for marshalling small or medium-sized data it will probably not have an impact. You could also implement a couple of monadic functions json.fromI and json.toBool to convert between representations.
14:40:25
@anaseto:matrix.organaseto I meant json.toI, not json.toBool (which is the same as json.fromI), of course. Also, from goal, you could define json.true:json.fromI 1 and json.true:json.fromI 0, and have JSONBool just be int internally too so that things map easily. 14:51:48
@anaseto:matrix.organaseto * I meant json.toI, not json.toBool (which is the same as json.fromI), of course. Also, from goal, you could define json.true:json.fromI 1 and json.false:json.fromI 0, and have JSONBool just be int internally too so that things map easily. 14:53:33
@_discord_1154759820042309762:t2bot.ioandradefr8_26148 joined the room.17:32:04
@semperos:matrix.fedibird.comsemperosGoal question: I'm seeing odd behavior when I sort a list of strings and then classify + index-count. If I remove sorting, I get the expected output. Any thoughts/suggestions on something I may not be understanding? https://gist.github.com/semperos/adcd74d945263654de713c182f13319b19:43:00
@_discord_624974820840308737:t2bot.iocoltim pow[;2]' is a verb there, because of the trailing '. so, if there is a noun to its left (a raw mean), it will use that as one of the arguments to pow[;2]' (which errors). when you use mean @ , the pow[;2]' verb ignores the left argument and does what you are looking for 20:18:57
@_discord_601584219743059998:t2bot.iosubsetpark oh interesting! so it's pow that's changing behaviour. but my intuition was partially correct that it's triggered by the fact that mean isn't a verb. 20:30:19
@_discord_624974820840308737:t2bot.iocoltim yeh. I think a similar issue would occur with mean -/ x, where mean would be treated as the left arg to -/ (which would error) 20:32:17
@_discord_624974820840308737:t2bot.iocoltim mean pow[;2] x would work though 20:40:01
@dzaima:matrix.orgdzaima (bridge had dropped:)
subsetpark: I'd like to check my understanding. Here's a spelling for standard deviation:
pow: {*/y#x}
mean: %/ (+/;#:) @\:
std: % mean @ pow[;2]' -/ 1 mean\
Without the @ between mean and pow, it's an error. My understanding is: that's because mean is not syntactically a verb, and so juxtaposition doesn't trigger function composition. If I replace mean with, say, +, then I no longer need to have the @ because + is a verb, and so it's unambiguous.
20:53:49

There are no newer messages yet.


Back to Room ListRoom Version: 6