What always bugged me in languages proclaiming type safety, was their Kantian thing-in-itself-ness. I mean, come on, to solve real world world problems, we would nevertheless need to parse alien JSON, or like. And all these IO monads, effects, etc are all just a compromise.
My experience with writing significant parts of business logic domain in Idris and then translating to Elixir, made me sure that I never need to write interop in Idris. On the boundary one might simply trust the developer, without any redundant criple handling. That clicked.
Cure doesn’t aim to be a general purpose language and it’ll never do. I do not even want to keep IO.println/1 standard lib (now I need it to simplify testing, later it might be needed for kinda logging, but still.)
Not pretending to try to be as generic as possible, simplifies things a lot. Before my lungs let me down, I was just running forward, as a wild cheetah, and I am grateful I am having this time without vim opened to rethink the approach.
I didn’t even settle on the syntax fully yet. Parser is isolated. I just wanted something less relying on a user’s math degree
That’s exactly why I explicitly stated I am not after a general purpose language. To accomplish a trivial program we already have bash script. Self-contained pure logic (think a bank transaction involving several sides) is something that might be isolated and then called from the outside. Boundary is still error-prone, but I am fine with that because it leaves a single place of failure and it still might convince the developer to try to prove the transaction itself.
Cure is by no mean a competitor to Elixir/Gleam/Erlang. I hope to keep a number of those writing 100% of the code in Cure limited to standard library maintainer(s).
Elixir/Gleam/Erlang users might cure out to perform some critical operation, or set of operations, or even a subsystem. If the input on the boundary of this interop might be trusted, there will be a mathematical proof that the outcome is to be trusted. That’s the goal.
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).
I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)
Linus (torvalds@kruuna.helsinki.fi)
I meant I do not expect to see projects written completely in Cure, because the whole purpose of Cure is to cover the parts needing the math proof and not cover anything else, inclusing but not limited to effects, IO and such.
I am explicitly after making it worth using, as an opposite to “avoid success at all costs.” That implies covering what makes sense to be covered and nudging users to get to more appropriate BEAM langs for everything else.
It does not. Even worse, if one node runs a BEAM compiled with Cure vN, and another one runs a BEAM compiled with Cure vM, all compile-time guarantees are compromised.
I never said dependent types are a silver bullet. I implied that despite I personally consider any type system without a dependent type to be a pure waste, dependent types might actually bring sorta better confidence in the running code.
Rolling deploys usually use different cookies, don’t they? But yes, thanks, I’ll mention it.
Actually, this particular issue was the culprit guilty in that OTP was not typed back in 80s, according to Joe and Robert. But nowadays I next to never saw anyone using hot-upgrade feature and if your genservers do not implement GenServer.code_change/3 callback, they are still very prone to issues running different versions on the connected nodes.
This might be considered a low-value reply, having nothing to do with Cure the language. It’s about the lovely design of the Cure logo/icon. It’s a nice combination of a caduceus and technical imagery. However (there’s always a however), the caduceus (two serpents around a rod with wings) is a symbol of Hermes/Mercury as messenger ( also a symbol of thieves and merchants). It is used by some to represent medical services, but in the interest of correctness and if you wanted to represent medicine, it would more properly be a rod of Asclepius (one snake, no wings). Obviously there was some confusion about snakes on a stick at some point in the past.
I’m sure there are not many that would notice or even care, but it’s obvious that some care and thought went into the design of the language (and the logo), so I thought I’d mention it. The logo looks cool with wings, though.
FWIW while this is internationally and historically correct, this subtlety has been eroded in modern US iconography over the last 125 years. My medical alert tattoo has the caduceus because more medical professionals recognize it over the rod of Asclepius as a medical sigil, laypeople doubly so.
The license (Apache2, same as Elixir) is added. To run examples do make clean && make all in the project folder and then ./run_cure.sh examples/14_pipe.cure. The handy compilation/running is pending.
What’s There
▸Pipes are monadic (see cure-lang/examples/14_pipe.cure at main · am-kantox/cure-lang · GitHub ). 5 |> double() would return Ok(10) assuming def double(x: Int): Int = x * 2, Ok(5) |> double() too. Error(“Nah”) as LHO would not attempts to call RHO and would be propagated.
▸ Peano arithmeticsNat declared as Succ(Succ(…(Zero))) is there, although I am not sure I am to keep it. Int and Float are to be [most likely] ditched in favor of Number.
▸ List and Vector are fully functional.
▸ Ok(T), Error(E), Result(T, E), etc.
Questions
▸ Shall I create kinda google group in addition to GH Discussions? I am not a big fan of groups myself.
▸ Shall I continue with typeclasses which are half-done or there is something more expected?
▸ What kind of tooling should come first (now the compilation is awkward.)
▸ Shall I make LSP fully robust before anything else (including SMT solver intergration)?
Fix and test the very very basics of your language
module Playground do
export [main/0]
def main(): Int =
1 + f()
def f(): Int =
3
end
Outputs
Error: Type Checking failed: {type_check_failed,
[{typecheck_error,"Failed to infer function body type",
{location,4,3,undefined},
{inference_failed,
{constraint_solving_failed,
{unification_failed,
{primitive_type,'Int'},
{function_type,[],{primitive_type,'Int'}}}}}}]}
I’ve been looking at the project since it’s release and it looks like most of it was generated without any testing. I’ve pulled it 3 times and make test never worked while make all worked just once, a week after it’s initial post on the forum. I would consider fixing bugs, creating CI and all of that before implementing new features
This is WIP. Some are already correct. This is currently top priority.
Ugh. Done.
Sorry for wasting your time.
I am not sure what does mean “generated,” I have tried Chez Scheme on the very early stages to generate code, but I failed. I use jujutsu as a home CVS and git exports might be creepy, I suppose. Tagged versions should compile though.
I doubt a comprehensive CI would have helped me in any way on the current stage, sorry. I even do not have a robust way to avoid full stdlib recompilation atm. And the new features is something I am after right now not because I love features for the sake of features, but because I manage to produce BEAMs and use them.
I am 100% agreeing with @Asd and I think by “generated” they mean “generated by an AI agent”. For example, when the commit message says “All tests are passing”, the tests were not actually passing
From my point of view it would help me see which commit is “good” and can be checked out locally to poke around, because so far I only wasted some time and learned nothing about the capabilities of the language / typesystem etc
I use jj for about 6 weeks now, and interacting with git repositories feels natural and seamless. I don’t have to have any strategy, I just push my changes…
