Some Questions to the overview document

[lochbrunner]

Bosque looks like a very promising modern language.

After reading the docs there are some points unclear to me.
Could you help me understand them?

I have sorted them after the sections in the overview document.

0.4

Why only typed strings, why no typed float/integers?
Then you could allow the compiler to check some arithemtic calculations

var a = 3m +2m;  // ok
var b = 3m + 2s; // error

Are they inspired by TypeScript?

0.6

Are there some typos?

Do you mean var! instead of var?

Why is the result of

var l = @[7, 8, 9];
// ...
l<+(@[5, 6]); //@[7, 8, 5, 6]

@[7, 8, 5, 6] and not @[7, 8, 9, 5, 6] ?

Typo here:

var r = @{f=7, g=8};
r@{f, h};         //@{f=1, h=none}

Should f be here 7?

What is the difference between

r<~(f=5, h=1);    //@{f=5, g=8, h=1}

and

r<+(@{f=5, h=1}); //@{f=5, g=8, h=1}

?

What is the difference of the merge and update operator for records?
For tuples the merge operator is an èxtend operator?

0.8

• .map does the same as |> map ?
  Why two operators . and |> doing the same?
  You state that . is always eager and only |> can be lazy.
  But this is not true, see Apache Spark or Rust Iterator Trait.
• What about introducing chainging or kleisli operators here?
  Like var y = (f | g | h)(x) which is the same as var y = f(g(h(x)));
• Does the |?> has a special purpose only for map?

5.7

What is the purpose of (Baz + Bar)::m(0) ?
Why not simply Baz::m(0) or Bar::m(0) ?

Others

Does the language also support floating point numbers?

[mrkmarron]

Thanks for the questions and comments.

0.4:
It is great to see you thinking about other use cases (units). It would be great to have a general notion of typed-X for ints, strings, etc. But we wanted to think more carefully about the design and uses before we committed to a specific design.

0.6:
Thanks for catching the typos. I have fixed them.
The <~ notation updates a set of named properties (or fields) while the <+ operator merges in the properties from an existing record without specifying the exact set. This is useful in combination with the project operators and allows you to do algebraic manipulations with records:

function foo(a: {p: Int, q: Int}, b: {x?: Int, y?: Int}): {p: Int, q: Int, x?: Int, y?: Int} {
    return a <+ b;
}

Basically it is a bag union on the property maps for the records/objects.

0.8:
We support two ways to process collections. Either step by step – all filter then all map – or element by element – filter and map 1 element before moving to the next. There are performance and clarity tradeoffs that can make either option preferable. So, we wanted to allow a programmer to use whatever worked best.

The |?> can be useful for many operators besides map – min/max, find, all, etc. You can see the current collection library functions in core\collections.bsq.

5.7:
Yes, doing (Baz + Bar)::m(0) explicitly doesn’t make much sense. However, it is possible for template instantiations to create this – e.g. the original code was T::c and then T is instantiated with Bar + Baz. So we wanted to make sure this was defined in a uniform/reasonable way instead of just having it be a type error.

Other:
Yes there if floating point support. But only in a library and a bit clunky right now. You can see it being used in the NBody application -- test\apps\nbody\main.bsq.

[dmytrol]

@mrkmarron Thanks a lot for elaborating!

I am still confused re algebraic data operations as described in 0.6 though, since they seem to allow modifications of records / tuples declared as immutable.

Is this intentional? Or, perhaps, should l and r be rather declared as

var! l = @[7, 8, 9];
var! r = @{f=7, g=8};

?

[mrkmarron]

The bulk update operations do a copy and update in the new copy. Here is an example:

var r = @{f: 1, g: 2};
var rc = r<~(g=5);

// r is still @{f: 1, g: 2}
// rc is @{f: 1, g: 5}

[mrkmarron]

Seems to be resolved and will be out of date with 0.1.o update.