News for hackers. Stuff that matters.
Re:Bosque Programming Language by xixixao on Thursday May 14, 2020 @01:35AM (#23175723)
I gotta say you lost me at args->allof

It’s 2020, if you’re really serious about building a new language, shouldn’t you at least pick a reasonable naming case convention? (allOf, AllOf, all_of, all-of would all work)

(Not talking about the fact that allOf doesn’t seem very consistent with other languages...)

Re:Bosque Programming Language by mrkmarron on Thursday May 14, 2020 @03:19AM (#23176430)
You are right, allof is inconsistent with the language naming conventions. I was updating some other collections support and made that fix as well. Thanks!
Re:Bosque Programming Language by dkersten on Thursday May 14, 2020 @04:55AM (#23177141)
My question is why -> instead of . for method/field access. I see almost all of the examples using -> but a few use . but unless there’s a difference (like how in C++ -> is a pointer dereference access), I think -> just adds noise to the syntax needlessly .

The documentation doesn’t appear to explain when to use one over the other, or perhaps . is a typo.

Re:Bosque Programming Language by Koshkin on Thursday May 14, 2020 @07:58AM (#23178407)
Agree, the arrow is syntactically redundant in C and C++ and does indeed make code look noisier that it could be. (The same can be said about the “four-dot” double colon.)
Re:Bosque Programming Language by TylerE on Thursday May 14, 2020 @01:57AM (#23175868)
all-of should not work unless your syntax for basic arithmetic is something heinous.
Re:Bosque Programming Language by dkersten on Thursday May 14, 2020 @04:51AM (#23177101)
Personally, I’m a fan of just requiring whitespace around operators. I find expressions hard to read otherwise, so think it’s bad practice, but I also find precedence rules awkward in all but the simplest expressions, so like to use parentheses a lot, which mean I don’t necessarily need whitespace-based grouping to make expressions clearer, eg: “a/b + c” I would just write as “(a / b) + c” anyway. I’ve been programming for 20 years so it’s not just unfamiliarity, I guess I just found these things cause me speed bumps needlessly.
Re:Bosque Programming Language by shakna on Thursday May 14, 2020 @03:17AM (#23176421)
Refusing to allow symbols in identifiers might make some things easier to read, but is annoying as hell if you're touching anything scientific.

If you have something clear you break tokens on, like whitespace (except within quotes), then you should have no problems allowing arbitrary symbols inside an identifier.

Re:Bosque Programming Language by TomMarius on Thursday May 14, 2020 @09:24AM (#23179185)

    x = 0
    y = 1
    x+y = 0
    z = x+y
What is z?
Re:Bosque Programming Language by traes on Thursday May 14, 2020 @11:31AM (#23180738)
x+y = 0 (with that specific syntax) will error in pretty much every language.
Re:Bosque Programming Language by TomMarius on Friday May 15, 2020 @04:44AM (#23190151)
So we will refuse to allow symbols in identifiers after all?
Re:Bosque Programming Language by traes on Friday May 15, 2020 @06:48PM (#23198433)
The only programming languages where arithmetic symbols are allowed identifiers have an identifier sigil (ala Perl, PHP), require whitespace around arithmetic (some teaching languages), or don't have conventional arithmetic syntax (e.g. Forth, Lisp).
Re:Bosque Programming Language by TomMarius on Saturday May 16, 2020 @04:31AM (#23201542)
Please read the comment I originally answered to.
Re:Bosque Programming Language by munro on Thursday May 14, 2020 @02:02AM (#23175919)
Or you're Lisp
Re:Bosque Programming Language by cygx on Thursday May 14, 2020 @03:33AM (#23176553)
Or The Language Formerly Known as Perl6 [1], where it won't cause much friction as variable names ordinarily start with a sigil.

[1] https://docs.raku.org/syntax/identifiers#Ordinary_identifier...

Re:Bosque Programming Language by traes on Thursday May 14, 2020 @02:23AM (#23176064)
Or you require whitespace in arithmetic.
Re:Bosque Programming Language by benibela on Thursday May 14, 2020 @08:52AM (#23178841)
Or XPath