« first day (52 days earlier)      last day (608 days later) » 

1:11 AM
Idea for gotos in Pytek: require that a directive must appear first in the code, written thus: @iknowgotosarebadandimstillgoingtousethem.
 
 
2 hours later…
2:58 AM
Hey @quartata, ye there?
 
Ye
 
Okay, I've been thinking about the named/unnamed args distinction, and I'm sorta confusing myself as to what their purpose should be. ...that's probably not particularly clear.
 
I didn't think there would be a difference functionality wise, just style
 
I was kinda thinking that too, like the use of [] or () is more of a semantic use than a real functional difference. It would make sense to allow default values for parameters in (), right?
 
Yeah
 
3:04 AM
I'm also thinking that you should be able to mix named args and unnamed ones, with the result that the unnamed args are assigned to the first parameters available.
Like, if I have func:foo[a=1, b=2, c=3]{\print(a,b,c)}, then I do foo[c=7, 5](), I should get 5 2 7.
 
I like that, although it might be a bit confusing at first
 
yeah
That will make it easy to just drop in a string for the first option.
 
How does that work in Python?
 
Named arguments must come after all unnamed arguments.
 
Ah OK.
Yeah I think this is better
 
3:09 AM
If you put all your default parameters in the options part, then that makes it really easy to override them; don't have to type their name!
 
Did you finish the second stage?
 
Not yet, I was at youth group for much of the past several hours. (I go to youth group because I still feel more like a kid than an adult, y'know? :P)
 
heh
 
Shouldn't be too hard though. All I need to look for is a = or a : (with func, op, type in front) to make the symbol table, and keep track of where I saw each of these.
 
I think we should actually try and do control flow after this.
 
3:14 AM
I'm actually gonna do the third stage next. I want to make it so that AST nodes don't handle their own execution, but that the object nodes tell the executor what to do.
And then we can do control flow.
 
Right, after that.
 
Anyway, what do you think of doing something like x += 5; \print(x) producing 5?
That is, variables have a default value (which will typically be falsy).
Actually, the answer to that question doesn't affect the symbol-table-building part. :P
 
Perl does it like that and it drives me nuts. If you mistype a variable name 99% of the time it will fail silently and annoy you
 
Alright, that's an emphatic "no". :P
Blitz 2D/3D also treats variables as having default values.
 
You're going to move function lookup to the third stage right
 
3:17 AM
Yes.
 
OK.
 
Well, actually, that might be in the second stage, during creation of object nodes.
 
What will happen to the big dictionary of built ins? Will those instead be moved to the symbol table?
 
Not totally sure yet.
I think I will indeed preinitialize the symbol table somehow.
Or just add the built-ins after parsing the user's code.
 
We need to redo that dictionary to use the new types
 
3:21 AM
Well yeah, there's gonna be a lot of re-doing. :P
 
It has that weird tuple of strings for keys
 
Yep, that's going out the window.
I'm going to make the objects handle addition and the like, though.
Not 100% yet how I'll handle precedence in cases where it's possible to convert two objects of different type to the other.
 
@El'endiaStarman ?
 
int and str, for example.
 
Oh
You may want to have a lot of overloads?
 
3:25 AM
How do you mean?
 
as in have a default for each of int + str etc
may not be what the programmer wants
so you may need a flag or something: intlike:string:'12345' or something
 
Well, you can do "5" int:+ "5" to coerce both arguments to integer before adding.
 
but that won't really solve precedence
 
I'm not sure what you mean. (And no, I'm not Marky.)
 
IDK
intlike on a non-int would make the interpreter use int:+ when it sees a plain + with an int
 
3:35 AM
How is that any better though?
 
@El'endiaStarman Then you need to think of some examples?
i.e. When will someone even do '5' + 5?
 
That's not a good argument against it. Also, consider this: x = 5 + \input().
 
Then it's probably a better idea to throw an error and inconvenience the programmer than to risk casting incorrectly?
 
If you're printing out the values of integer variables, you might be doing something like x = 5; \print("x: "+x), and it's a pain to have to convert x to a string every single time, like I encounter in Python.
 
Then have JS-style \print("x: ", x)?
then have a function to print each type
 
3:41 AM
I can do that in Python. It inserts a space though.
What I described works that way in Blitz 2D/3D and it's pretty convenient.
 
\print[separator='']()?
@El'endiaStarman ?
 
That'll be an option.
But dude, it's so much easier to just allow "x: "+5.
 
And given that I want that, then I should not get different and unexpected behavior if the string can be parsed as an integer.
 
@El'endiaStarman Doesn't this contradict allow "x: "+5?
 
3:44 AM
@MarsUltor What? No.
 
> it's a pain to have to convert x to a string every single time, like I encounter in Python.
how else would it work?
 
.....
x = 5; \print("x: "+x) would produce "x: 5".
 
I know, but what would it do if ot doesn't convert to string every single time?
 
Python complains.
>>> print("x: "+5)
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    print("x: "+5)
TypeError: Can't convert 'int' object to str implicitly
 
4:06 AM
> But dude, it's so much easier to just allow "x: "+5.
is confused
or maybe you should make the concat operator different
 
I'm seriously considering having a distinct concat operator.
Not sure what symbol to use though.
I think at least one other language uses ..
 
php uses .
infix ++ would probably be too confusing
&+ or something?
IDK, & is concat in VB and MS Excel
 
Planning on that for logical and though.
 
it's || in SQL
 
Could do that since it's not reserved for anything. Though, if we're okay with the potential confusion of ||, we should probably be okay with the potential confusion of ++.
 
4:15 AM
but looks too much like short-circuit logical or
if you aim to have distinct short-circuit/non-short-circuit
 
I do plan on really emphasizing in the Pytek tutorial that a lot of traditions/conventions have been/are being broken, so we could just do ++ for concatenation anyway.
 
but ++i ++ i++ will look weird (not that that is ever gonna be used)
may be difficult to parse too
 
I don't think I'll have ++ be increment.
 
okay then
so it'll be something more like 'i ++ i' (like Jelly)? (a lot more readable)?
 
Yeah. We could do "5" + 5 => 10 and "5" ++ 5 => "55". What do you think, @quartata?
 
5:10 AM
Any idea what comments will look like?
TeX's % won't work because that's mod
 
5:53 AM
Comments will be #, like Python.
 
 
9 hours later…
2:48 PM
How about "5" << 5?
@El'endiaStarman
 
 
2 hours later…
4:53 PM
@quartata Oh, that's a good idea.
Should >> reverse the arguments and then concatenate?
I mean, reverse the order of arguments.
 
hmm
By the way, we're going to have a similar issue for string multiplication
Perl uses * for numbers and x for repeat
 
in The Nineteenth Byte, 12 hours ago, by El'endia Starman
And, y'know, I haven't really implemented much of anything beyond working on the parser. I'm probably gonna make concatenation ++ (it won't be an increment operator), so I could probably do +* for repetition and make + and * vectorize by default.
 
Ah, OK
 
Do you think that's a good idea?
Like, seriously, (almost) nothing is set in stone. Now is the time to change before we get more users.
 
I do think + and * should vectorize by default. I'm not sure I like +* as a symbol
Would it be weird to do ^ for exponentiation and o for XOR?
 
5:06 PM
Logical or bitwise? If we made all boolean operations words, that would free up additional symbols as well.
 
Logical
I was thinking o is kinda like
but not really :PP
We could just do a xor b
 
And bitxor for the bitwise version.
 
5:44 PM
Circle will be hard to type
** will be multiplication via concat then?
 
Don't know for sure yet.
 
Um
I mean that would kinda make sense
@El'endiaStarman but then those symbols may not be used for other things
 
Ye sure? I've been in want of symbols from like day one. :P
But if we use only words for boolean ops, then that frees up &, |, ^, and ~.
 
If you find a good use, sure. But it may be confusing
 
@MarsUltor It's just an o
 
5:50 PM
I'm not worrying about initial confusion. My goal is "Oh, that makes sense." after explanation.
 
Well, yeah. I'm not sure if much would make sense using those symbols
 
Ha, that won't be a problem.
 
^ = exponent, & could have been concat
 
& doesn't make much sense for concat.
 
If ^ is exponentiation, we could use ** for repeated concatenation.
 
5:54 PM
Well, it's used as concat in (very few) languages
 
That doesn't mean it's a good idea
 
*& is
Hmm
So
What are some commonly used functions?
 
@MarsUltor How do you mean?
 
Like js's Array.includes (assuming that will be python-style infix in so that won't be slow to type)
 
Eh? Example?
 
6:00 PM
Any function with a long name common enough that it merits a symbol?
 
Well, in will be in Pytek just like it is in Python.
 
Maybe they can be reserved for python style decorators and other syntactic sugar like that?
 
We already have @ for directives.
Including includes.
 
Okay, so probably best to leave them free for now
 
Yeah. Y'know, maybe I could make two of those replace \pair() and \each().
They'd be unary operators that operate on operators. :D
 
6:12 PM
What
What do they do
 
Actually, come to think of it, if + and * vectorize automatically and we have ++ for concatenation, \pair() will be unneeded most/all of the time.
 
@El'endiaStarman ?
I think << and >> should stay the same as normal
Unless you want to turn those into words as well
 
bitshiftleft or just bitleft, and likewise for right shift.
I mean, really, I've never actually used << and >> in Python programming.
You can do the same thing with *2 and //2.
Well, only for << 1 and >> 1, but still.
 
6:27 PM
<< is used for append in lots of languages actually
 
I was thinking that ++ could be used for appending as well.
What else would [1,2,3] ++ 5 mean?
Now, if you wanted to append a list to a list...
 
++ means append the item, list + list means concatenate.
 
6:45 PM
But + will vectorize automatically, so list + list will add each pair and make a new list.
Also, I'm talking about stuff like [1,2,3].append([1,2,3]) => [1,2,3,[1,2,3]].
 
7:13 PM
Then +++.
Problem solved.
 
Hah, no.
 

« first day (52 days earlier)      last day (608 days later) »