On Fri Aug 23, 2024 at 12:52 PM BST, Lorenz (xha) wrote:
> On Fri, Aug 23, 2024 at 10:41:48AM +0100, Byron Torres wrote:
> > > On Thu, Aug 22, 2024 at 10:08:07PM +0100, Byron Torres wrote:
> > > > Idea for select statement:
> > > > 
> > > >     select {
> > > >     case let x = <~ch =>
> > > >             ...
> > > >     case ch<~ 1 =>
> > > >             ...
> > > >     case =>  // optional case. selected if all other cases are blocking
> > > >             ...
> > > >     }
> > > > 

On Fri Aug 23, 2024 at 12:52 PM BST, Lorenz (xha) wrote:
> > > > : fiber
> > > > A thread-managed non-preemptive, cooperative (explicitly yielding)
> > > > routine, made up of stackful asymmetric coroutines.
> > > > 
> > > > * Stackful means yields pauses all stacks upto the parent spawner as one
> > > >   large stack.
> > > > 
> > > > * Asymmetric means yield does transfer control to another coroutine
> > > >   directly.
> > > > 
> > > > Conceptually, fibers interleave on the thread they belong to, which
> > > > could be on many cores, which makes little difference to the
> > > > programmer's idea of control flow.

Some rebuttals.

On Fri Aug 23, 2024 at 7:57 AM BST, Lorenz (xha) wrote:
> thank you very much for the feedback! lots of comments inline.
>
> On Thu, Aug 22, 2024 at 10:08:07PM +0100, Byron Torres wrote:
> > : task
> > The most abstract, general idea of a "task".
> > Not a special kind of routine, as Lorenz has suggested.
> > I know some programming languages have adopted this term,
> > and I'm wholly against it. I plead that it does not become a keyword.
> > Tasks as a user defined thing inside an application is OK.
>
> i think that this is a very good term and much better than "fiber"

# multitasking vision

Thank you so much, Lorenz, for this write up. I strongly agree that in
today's and tomorrow's multicore world, it is important for a low level
language like Hare provide at least good comfort for multitask
programming. Your outline is something I've been wanting to do but
couldn't.

I'd like to outline my own rough vision for Hare multitasking, propose
some changes, and compare and critique your proposal.

My ignorance in certain domains will show. I'll do my best. This write
up is also partly to be the voice of the layman, asking dumb questions,
learning, etc.

On Wed Aug 21, 2024 at 10:05 PM BST, Ye Wison wrote:
> Ok, thanks for the quick reply. Actually, I created my custom format
> string at the runtime instead of using string literal and it works as
> expected:
>
> ```hare
> //
> // Create the format string I want, the output looks like this:
> "{:-36} {:6} {:12}"

FYI, creating layout strings like this is inefficient if these strings
are not being used for anything else. Consider using fmt::mods, which
was made to avoid this problem. Search for "parametric format modifier"
in `haredoc fmt`.

Hi Ye,

On Wed Aug 21, 2024 at 8:42 AM BST, Ye Wison wrote:
> "{:item_name_fixed_len} {:ITEM_SIZE_BUF_LEN} {:ITEM_SIZE_DATETIME_BUF_LEN}",

Hare does not have special string escape syntax like Python.
The compiler just sees this as a normal string.

It is the fmt:: functions that parse each character of the string at
runtime, finds this string pattern, and substitutes it with a new
string.

That's why the error is from the fmt:: function

On Tue Aug 20, 2024 at 12:36 PM BST, spxtr wrote:
> I'm not sure I follow.
>
> >	// first style
> >	type State = struct{
> >		entity1: Bool: (Bool | void) = void,
> >		entity2: Bool: (Bool | void) = Bool{ value = true },
> >	};
> >
> >	// second style
> >	type State = struct{
> >		entity1: Bool = void: (Bool | void),
> >		entity2: Bool = Bool{ value = true }: (Bool | void),
> >	};

On Tue Aug 20, 2024 at 1:49 PM BST, davawen wrote:
> >  	let x: AnyType = 42: BarInt;
> >  	let z: AnyType = void: PosInf;
> >  	let y: AnyType = true;
>
> This time, the exact same *semantics* apply,
> the only difference is we need to put the casts 
> explicitely since they are ambiguous, and we do on the expression side because they 
> happen at runtime.

Hmm, fair point about runtime semantics.

Struct definitions are wholly a static compile time thing. Maybe it
would make sense to have "runtime expressive" code (e.g. default

On Mon Aug 19, 2024 at 7:07 PM BST, spxtr wrote:
> What is the advantage of putting "casts" on the types, rather than on
> the default values? Or, why
>
> >	type Struct = struct{
> >		bar: int: Foo: Bar = 2,
> >	};
>
> over
>
> 	type Struct = struct{
> 		bar: Bar = 2: int: Foo: Bar,
> 	};
>

# addendum for specifiable struct field tagged union member type default

I believe this proposal is sensible and warranted, and I have come
across enough real world sitations where I consider this a nuisance
problem, and wish Hare would alleviate this problem for me.


## default types

Specifically, the problem of autofill, of no default *type* for tunions
(tagged unions) in struct fields, where there's no *zero-value* at all.
I consider it secondary the problem of no default *value* for tunions
struct fields, and tertiary the problem of no default value for *any
kind* of struct fields, though still plenty cause for concern.