Fix the grammatical error: The Bosque programming language is designed for writing code that simple, obvious, and easy to reason abo
The Bosque Programming Language
41–50 of 172 posts
Re: The Bosque Programming Language
#42Hi project owner (Mark) here. It is a bit late in the evening for me but I will try to answer any questions when I can. The Bosque language is currently in a very early state with lots of work to do and not ready for practical use. However, I am very excited by the potential in the concepts and wanted to make the project a collaborative endeavor, including both other academics and developer community, from the start.…
You seem to have some goals in common with Floyd. Maybe you want to get in touch.
https://github.com/marcusz/floyd https://www.reddit.com/r/ProgrammingLanguages/comments/arwjl...
Re: The Bosque Programming Language
#43A random thought about the code samples. What do we gain from having to write point instead of other languages' point.y = value ? I believe that syntax should be designed to make things simple for developers, not for the designers of languages or for compilers.
"point.y = value" is typically a statement for a single update of a mutable record. I'm not sure how you'd extend the latter to support the features of the former. The meaning is completely different. Different things should look different.
I expand a little my point. This is from Elixir, functional and immutable, which I've been working with for a couple of years
iex(1)> point = %{x: 1, y: 2, z: 3}
%{x: 1, y: 2, z: 3}
iex(2)> point.x = 4
** (CompileError) iex:2: cannot invoke remote function point.x/0 inside match
iex(3)> Map.put(point, :x, 4)
%{x: 4, y: 2, z: 3}
iex(4)> %{point | x: 4}
%{x: 4, y: 2, z: 3}
iex(nope)> point.x = 4
%{x: 4, y: 2, z: 3}
Re: The Bosque Programming Language
#44Hi project owner (Mark) here. It is a bit late in the evening for me but I will try to answer any questions when I can. The Bosque language is currently in a very early state with lots of work to do and not ready for practical use. However, I am very excited by the potential in the concepts and wanted to make the project a collaborative endeavor, including both other academics and developer community, from the start.…
Hello, no offense but the community here is bikeshedding. I'd suggest you to discuss this at /r/programming
They're bikeshedding there as well. Just filter out any post that contains the word syntax.
Re: The Bosque Programming Language
#45Earlier quoted context omitted.
"point.y = value" is typically a statement for a single update of a mutable record. I'm not sure how you'd extend the latter to support the features of the former. The meaning is completely different. Different things should look different.
I expand a little my point. This is from Elixir, functional and immutable, which I've been working with for a couple of years iex(1)> point = %{x: 1, y: 2, z: 3} %{x: 1, y: 2, z: 3} Of course this doesn't work iex(2)> point.x = 4 ** (CompileError) iex:2: cannot invoke remote function point.x/0 inside match This is how we do it, verbosely iex(3)> Map.put(point, :x, 4) %{x: 4, y: 2, z: 3} Or with a syntax shortcut iex(…
The problem with the last code snippet is that it looks like mutating the original value, and that would mislead newcomers to the language.
Re: The Bosque Programming Language
#46Hi project owner (Mark) here. It is a bit late in the evening for me but I will try to answer any questions when I can. The Bosque language is currently in a very early state with lots of work to do and not ready for practical use. However, I am very excited by the potential in the concepts and wanted to make the project a collaborative endeavor, including both other academics and developer community, from the start.…
There's an English error on the very first sentence of the description on the Microsoft site.
> There's an English error on the very first sentence of the description on the Microsoft site. [emphasis added]
The correct usage would be to talk about an error "in" a sentence, not "on" a sentence.
Muphry's law get you every time!
Re: The Bosque Programming Language
#47Earlier quoted context omitted.
I expand a little my point. This is from Elixir, functional and immutable, which I've been working with for a couple of years iex(1)> point = %{x: 1, y: 2, z: 3} %{x: 1, y: 2, z: 3} Of course this doesn't work iex(2)> point.x = 4 ** (CompileError) iex:2: cannot invoke remote function point.x/0 inside match This is how we do it, verbosely iex(3)> Map.put(point, :x, 4) %{x: 4, y: 2, z: 3} Or with a syntax shortcut iex(…
The problem with the last code snippet is that it looks like mutating the original value, and that would mislead newcomers to the language.
Yes, that's possible. However this is an example from Ruby, which is very mutable but has some immutable features in its standard library.
2.3.0 :001 > s = "abc"
=> "abc"
2.3.0 :002 > s.gsub("b", "B")
=> "aBc"
2.3.0 :003 > s
=> "abc"
2.3.0 :004 > s.gsub!("b", "B")
=> "aBc"
2.3.0 :005 > s
=> "aBc"
iex(1)> s = "abc"
"abc"
iex(2)> String.replace(s, "b", "B")
"aBc"
iex(3)> s
"abc"
iex(4)> s = String.replace(s, "b", "B")
"aBc"
iex(5)> s
"aBc"Re: The Bosque Programming Language
#48A random thought about the code samples. What do we gain from having to write point instead of other languages' point.y = value ? I believe that syntax should be designed to make things simple for developers, not for the designers of languages or for compilers.
Or to use Scala's syntax which is more clear to me:
point.copy(y=value)Re: The Bosque Programming Language
#49A random thought about the code samples. What do we gain from having to write point instead of other languages' point.y = value ? I believe that syntax should be designed to make things simple for developers, not for the designers of languages or for compilers.
Or to use Scala's syntax which is more clear to me: point.copy(y=value)
I really like F#'s approach to this
let point2 = { point1 with y = value }
EDIT This is inherited from OCaml - https://v1.realworldocaml.org/v1/en/html/records.html#functi...
Re: The Bosque Programming Language
#50> Thus, Bosque does not have any undefined behavior I think this is the one that should be highlighted most. Otherwise, from an engineering perspective, many of the other language features have already been implemented and widely used in other languages
I think I remember someone talk about undefined behavior in specifications and how it is actually a good thing, in the sense that offers increased liberty for implementations and some other advantages. Anybody else has heard this? Don't quite remember where I read it. My humble opinion aligns with yours, it seems intuitively "better" to have no undefined behavior. https://en.wikipedia.org/wiki/Undefined_behavior#Risk…
Especially in C-like languages, undefined behavior is one of the main things that creates space for compilers to get better (produce faster code, or produce code faster, or smaller, etc). That topic comes up in compiler discussions every so often; I would hazard a guess that one of those references is what you have in mind.