this post was submitted on 30 Jan 2024
7 points (100.0% liked)

Programming Languages

1186 readers
1 users here now

Hello!

This is the current Lemmy equivalent of https://www.reddit.com/r/ProgrammingLanguages/.

The content and rules are the same here as they are over there. Taken directly from the /r/ProgrammingLanguages overview:

This community is dedicated to the theory, design and implementation of programming languages.

Be nice to each other. Flame wars and rants are not welcomed. Please also put some effort into your post.

This isn't the right place to ask questions such as "What language should I use for X", "what language should I learn", and "what's your favorite language". Such questions should be posted in /c/learn_programming or /c/programming.

This is the right place for posts like the following:

See /r/ProgrammingLanguages for specific examples

Related online communities

founded 1 year ago
MODERATORS
armchair_progamer
7
Question: Any Serialization Lang for Pure Functions (lemm.ee)
submitted 10 months ago by [email protected] to c/programming_languages
8 comments fedilink hide all child comments
 

JSON and YAML work great for passing data between languages.

However, sometimes, I have a pure function like y = mx + b, that I would like to pass between languages (for making plots).

What operators should be available? I think jsonnet's standard library(skip to the math operators) is the perfect example of a useful set of operations that could be shared across basically all programming languages. The operations would take/return json values rather than working with language-specific data types.

My question is does such a language exist already?

Close candidates:

  • Dhall and jsonnet are pure languages that generate json. But AFAIK they can't actually serialize pure functions. They can only use pure functions as a shorthand for generating json. I want to actually save/send functions over the wire.
top 8 comments
sorted by: hot top controversial new old
[–] DrDeadCrash 4 points 10 months ago* (last edited 10 months ago) (1 children)

What do you think about compiling to wasm, for these logical inter-exchanges?

[–] [email protected] 2 points 10 months ago (1 children)

I think that's actually a pretty good idea.

I could, right now, create the function in wasm, put it in yaml with a !wasm tag (or maybe a more specific tag) then the deserializer could detect it, load it, and wrap it in a function.

[–] DrDeadCrash 3 points 10 months ago (1 children)

Check out the ABI concept, if you haven't found it yet:

https://www.webassembly.guide/webassembly-guide/webassembly/wasm-abis

[–] [email protected] 1 points 10 months ago* (last edited 10 months ago) (1 children)

I would actually intentionally not want any ABI like wasi or emscriptem. I'd like the serialization format to not care about the platform at all (e.g. the function should run the same on any operating system, browser, embedded device, etc).

[–] DrDeadCrash 3 points 10 months ago (1 children)

Wouldn't this serialization format need to be implemented in every language that that needed interoperation? How does that differ from an ABI?

https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9

[–] [email protected] 1 points 10 months ago* (last edited 10 months ago)

I think maybe this is just a communication issue and we actually agree on the details.

Wasi and emscriptem from the ABI link, AFAIK, are basically wrappers to impure tools; console log, file system access, sockets, etc. For my usecase, I dont want the serialized functions to have access to those interfaces.

That aside, lets say we serilized (m: f32, x: f32, b:f32): f32 => m*x + b. Yes, there will need to be some conversion layer, like converting python floats into wasm f32 floats and converting the f32 output back to python float. And stuff like javascript not having ints, could cause some weirdness. Maybe thats the ABI you're talking about. Since that conversion basically already exists for every language that supports wasm, I didnt really think of it as an ABI, but you might be right that techically it is an ABI.

I suppose a real ABI would be needed if the wasm function wanted to manipulate complex types like hashmaps or arrays.

The serialization format could just be the bytes of a wasm file stored inside of a yaml file in base64. I'm not sure if yaml or utf8 would be considered a ABI. But basically the bytes would be loaded as a wasm module, then the wasm function inside the module would become value for that yaml key. The wasm function would be auto-wrapped by the language's default inter-op layer for wasm functions.

[–] [email protected] 2 points 9 months ago

I think S-expresions are an often overlooked encoding and when used on code it results in a lisp dialect.
The main advantages are no ambiguity, easy parsing/interpretation and lisp being an established language family, the main disadvantage is a lot of parentheses.

Now for some barely relevant rambling: By implementing your own simple lisp dialect you can tailor it to your own needs by simply not implementing IO or even limiting computational complexity by limiting recursion and not allowing first class functions.

[–] armchair_progamer 0 points 10 months ago

Code is data.

I would just transmit the program as source (literally send y = mx + b) instead of trying to serialize it into JSON or anything. You'll have to write a parser anyways, printing is very easy, and sending as source minimizes the points of failure.

Your idea isn't uncommon, but there's no standard set of operations because it varies depending on what you code needs to achieve. For instance, your code needs to make plots, other programs send code for plugins, deployment steps, or video game enemies.

There is a type of language for what you're trying to achieve, the embedded scripting language ("embedded" in that it's easy to interpret and add constants/hooks from a larger program). And the most well-known and well-supported embedded scripting language is Lua. Alternatively, assuming you're only using basic math operators, I recommend you just make your own tiny language, it may actually be easier to do so than integrate Lua.