--
---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZsczGWudHSnzDS6%3D9na-oyO5E6qKrqa3A3hrCouVt8KXg%40mail.gmail.com.
So I guess you're taking the developments from Rust as a starting point for your own designs. What I was wondering is whether it would be interesting to explore the GALS paradigm that you mentioned by mixing the synchronous (local) concurrency semantics with some actor-based model. The latter need not be part of the language, but maybe it could be something to keep in mind in designing the language so that (for example) writing a library that gives actor-capabilities would be possible.
Also, have you looked at Pony and its type system? What is your opinion on that? To be clear: I have no experience with writing either Rust or Pony, so I have no personal stake here, just curious what your opinions are.
Sounds neat. Thanks for all of the great work.
I like that you included "simple" in the description. I imagine a
simple language is much harder to design, but pays off in the long
run.
I think strong type systems can be useful, but
should always come with an escape button. Some way to annotate, cast,
or otherwise tell the compiler to continue even when it can't prove
type safety. I think there will always be valid programs that you
can't get through a type checker, and it can be really tiresome to
have to fight the compiler.
- The interop with C is really useful. If you are going to have a
vector type again it would be useful to make it available to/from C.
This would be used for sharing data between the two domains without
having to fall back to some user defined C type.
- I wonder if not using a stack for emit might be a reasonable idea.
Maybe turn emit into a yield that will resume on the next event loop.
I know it would change the semantics, but it would get rid of the
possibility of a stack overflow. I've inadvertently written some nasty
emit hairballs and it can be hard to debug on something like an
arduino. Or maybe have an emit/yield statement to opt out if the stack
semantics are necessary. Or be able to detect a stack overflow and
somehow flag it through something like a PANIC event.
- Adding a yield statement would make it easier to break up async
code. Right now only loop can do that.
- I think the organism idea (I forget what you call them now) is
neat. It would be quite useful to be able to await methods as well.
- I've needed flow control on a number of occasions and emits are
easily lost if an await is not ready. Maybe have an emit/await
statement that will block the emit until a matching await is ready to
accept. I've come up with manual approaches, but it's easy to get
wrong.
Yes. This is very aligned with my goals.You can have very complex type systems in which you can encode 99% of your problems.Even there, 20% are still very hard to encode in the name of soundness and you spend hours just to realise a few days later that you actually won't use that code.For the remaining 1% it might either be impossible or very hard to encode, may using a second language.I aim for 80% soundness and the remaining 20% should be very easy to workaround.This is one of the reasons why I believe source compatibility with C is so important. The types, expressions and statements bridges between C->Céu and Céu->C should be a few keystrokes away with zero conversions.
That's not the first time I see people questioning the stack semantics.I'd be happy to see these hairy examples simplified to discuss.It should only be possible to have a stack overflow if you have a loop w/o an external await.You can always use an "async do end" as an yield, but it's a code smell.In some situations, internal emit/await should be substituted by "spawn" of some "code/await".
- Adding a yield statement would make it easier to break up async
code. Right now only loop can do that.
I didn't understand this one.
It's called "code/await" and will probably be renamed to "task".If you substitute "code/tight" (method) to "code/await" you can await a method. This is already supported.
- I've needed flow control on a number of occasions and emits are
easily lost if an await is not ready. Maybe have an emit/await
statement that will block the emit until a matching await is ready to
accept. I've come up with manual approaches, but it's easy to get
wrong.
Again, this seems like you should "spawn" something instead of "emit".
--
---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZt3n%2Br_ZxWJi2HZ%2BK0dk4dHstdk0ysnQcVRYmgD3qx-YA%40mail.gmail.com.
- Adding a yield statement would make it easier to break up async
code. Right now only loop can do that.I didn't understand this one.An example:async do// loop will send control back to the main event looploop do// some code here...takes 0.5 seconds...// a yield might be used to return control to the main loopyield// more code here...takes 0.5 seconds...endendI've written some code that is fairly cpu intensive, not so much that I want a separate thread, but enough that I still worry about staying responsive to an external event. Async is a good fit, but having a yield statement that I might call from within an async block might be useful. Would the "async do end" trick work here; i.e. nested?
It's called "code/await" and will probably be renamed to "task".If you substitute "code/tight" (method) to "code/await" you can await a method. This is already supported.I forgot that it was in the roadplan, but I don't think it's currently supported by the ceu compiler right now. It's nice to know Ce will have it.
- Is there value in turning par/or and maybe even par/and into expressions that return values?
- Is there value in being able to pause and resume a running process? Maybe I have a deeply nested par statement and I want to pause but not cancel the whole tree.
I see. So these codes that take 0.5 seconds are not loopsI'm asking this because Céu inserts an yield automatically at the end of every loop iteration.If they are not loops, are they native calls? This is the only situation I can imagine in which you would require an yield in the middle of an async loop.
Céu already supports this:The "Worldmap", "Story" and "Credits" are methods (code/awaits) that execute sequentially and are awaited in the call site.
Yes! This is very interesting and is supported with "pause/if":
--
---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZvOOsF0NpDEg%2Br73_v97K6hZg1MEX506itp_nXqTE7zbA%40mail.gmail.com.
I see. So these codes that take 0.5 seconds are not loopsI'm asking this because Céu inserts an yield automatically at the end of every loop iteration.If they are not loops, are they native calls? This is the only situation I can imagine in which you would require an yield in the middle of an async loop.Yes, a series of native calls that take some cpu time, but aren't necessarily in a nested loop.
Céu already supports this:The "Worldmap", "Story" and "Credits" are methods (code/awaits) that execute sequentially and are awaited in the call site.This was an interesting read. I think I wasn't clear on what I meant with the organism method.Something like this, but it raises a compiler `not implemented error`.
Just a curiosity. Why implement it using kotlin instead of c/lua like ceu?
As some evidence, Rust programmers xxx the type system use numeric indexes and/or reference counting, which are both poor solution in comparison to synchronous concurrency enables.