Pytek - 2016-02-09

« first day (1 day earlier) ← previous day next day → last day (659 days later) »

El'endia Starman

12:31 AM

Oh, by the way, thoughts regarding list/sequence slicing:

It's somewhat annoying to have to do stuff like L[i:i+2] to get the two elements at position i. Wouldn't it be nice to be able to do L[i:+2]?

Python allows a step argument in slicing, so L[::3] will get every third element. What if I want every third element plus the following element? (I.e., [0,1,2,3,4,5,6,7,8,9] => [0,1,3,4,6,7,9].)

That requires not only a step argument but a chunk length too.

Oh, and what if the step argument could be a sequence?

[0,1,2,3,4,5,6,7,8,9][ \N**2 ] => [0,1,4,9]

Not only a sequence, but an infinite one too?

I had this notation written on the board, from a couple weeks ago (I think): L[a:b;c,d] where a is start index, b is end index, c is the step, and d is the chunk length.

El'endia Starman

12:55 AM

I could make them all colons. But L[i:::2] seems a bit silly.

What would L[:::2] even be? Maybe that could be equivalent to \chunk(L,2), where \chunk([0,1,2,3,4,5],2) => [[0,1],[2,3],[4,5]].

1 hour later…

El'endia Starman

2:22 AM

What do you call a broken record that doesn't repeat?

1 hour later…

3:52 AM

@El'endiaStarmana You might want to look into how perl's splice works; it uses a slicing notation similar to what you're describing

El'endia Starman

@quartata I think I've seen you share a link to that in chat, but I couldn't really parse the doc.

oops nevermind

I was thinking of something else

El'endia Starman

Nonetheless, @quartata, thoughts on the best way to do notation for subsets of lists?

I'd like to use as few characters as possible across all use cases, so to speak.

4:08 AM

I think something like [start:end:<step>:<chunks>] is good. If step is not satisfied, it should create a nested array of chunks.

Like [1,2,3,4][:::2] -> [[1,2],[3,4]]

El'endia Starman

What about [start:end|step:chunks]?

I was literally just about to mention that.

El'endia Starman

haha

[:::2] could be replaced with [|:2].

That way it could be say [|:2]

El'endia Starman

:P

4:11 AM

ninjad

I'm feeling slow today.

El'endia Starman

You waited to see whether I would say "ninja'd"? :P

Hm I wonder if a pipe is the best separator aesthetics wise

El'endia Starman

yeah

[| looks a little weird.

Plus it could be used for OR.

How about a semicolon?

El'endia Starman

I did use ; earlier, but if I'm going to use that to end statements...

Well, it can be context sensitive, no problem.

4:13 AM

Right but inside the array it is OK

El'endia Starman

[start:end;step:chunk]

Little extra parsing work

El'endia Starman

[;:2]

I actually don't mind putting more work on the parser.

It might be hard, but it's a one-time thing, basically.

Ooh. You could use @ or $.

$ looks OK.

El'endia Starman

[1:3$5:7]

That looks confusing.

Plus, if I use $ for self-reference...

Which, incidentally, I picked $ for because it's like an S, the first letter of "self".

4:16 AM

So $ is like this?

El'endia Starman

hmm

Or like APL's delta?

El'endia Starman

Not exactly, though yeah, I should come up with something for that.

How's APL's delta used?

It's recurse. Calls the current function.

El'endia Starman

hmm, close

x = $+1 produces the natural numbers (if x = 0 is done beforehand).

4:18 AM

Ohh.

El'endia Starman

I feel like that's a really weird concept that could be very powerful.

So it makes a mini generator?

El'endia Starman

As I said earlier, the following would produce the Fibonacci numbers:

a,b = 0,1
a,b = $2,$1+$2

That is cool.

El'endia Starman

Oh, incidentally, ranges: 1..20.

The double-dot syntax.

4:21 AM

... for exclusive?

El'endia Starman

Hmm...

1.,20?

I'd also like to figure out how I could incorporate step and chunk in there too, but that might be asking too much.

You can always just (1..20)[;2:]

El'endia Starman

true

Or even 1..20[;2]

Slicing doesn't make sense on integers, therefore...

That might lead to some weird bugs though.

So .. takes precedence over [

El'endia Starman

It could, yeah.

But what if you do 1..x and there's a chance x is a list?

4:24 AM

Oh. yea.

El'endia Starman

Another possibility: [2,4,...,2*_,...], which the parser could be smart enough to figure out.

The advantage of this is that you can do more-complex sequences easily.

All square numbers? [1,...,_**2,...]

'course, there's gotta be a better way.

[_**2](\N)

I've also been thinking about angle brackets.

I want to keep them for less-than and greater-than, but they could also be useful as a fourth bracket pair.

!!!

\N[_**2]

Would that make sense?

What does \N do?

Oh. I see.

The first format makes more intuitive sense but the second on is cleaner. Tough trade off.

The second one is probably better.

El'endia Starman

hmm

\generate[...]

El'endia Starman

How about {_**2|\N}?

@quartata Hmmmm...that could work. Maybe. \generate[\N](_**2)

4:35 AM

@El'endiaStarman It would make it more obvious.

El'endia Starman

The advantage of the {|} notation is that it draws from mathematics.

@quartata Very true.

I like the set notation one but it is ambigious; it could be a code block.

El'endia Starman

\generate[\N;_%2==0](_**2) for squares of even numbers.

@quartata Yeah. Perhaps I should reserve {} for code blocks, period.

Lexing this is going to be...

El'endia Starman

Though, considering their use for dictionaries in both Python and JS...

4:39 AM

I encourage you not to do Python's : code block style. It makes code harder to follow IMO

El'endia Starman

@quartata Considering how nontraditional the notation seems to be becoming, I'm not sure any already-written lexer or parser could handle it. :P

I was planning on writing one myself anyway, and building the AST along with it so it's context-aware.

@quartata I might disagree, considering I basically grew up with Python. :P

That said, I'm already planning on using it for type specifiers.

a = "hi" will be a standard Python-esque variable, whereas int:a = "hi" will throw an error because a must be an int.

This reduces the need for if type(a) != int: return TypeError("a must be an integer").

And still allows the flexibility of Python's typing system.

Whie i'm here I might as well suggest a few Perl-esque things...

Make =~ regex

El'endia Starman

How's that used?

string =~ /match/ or =~ s/sub/stitute/

El'endia Starman

hmm

I'll consider it.

4:47 AM

An operator that when passing an array to a function will flatten it.

El'endia Starman

Definitely planning on that.

Though it might just be \flatten().

I'm probably also gonna borrow Python's splat operator: *.

>>> def foo(a,b,c):
	return a+b+c

>>> foo(*[1,2,3])
6

I think a splat operator is what I am trying to describe but I wouldn't know. Perl does this automatically so

El'endia Starman

It doesn't flatten the list, though. It unpacks it.

yeeh that is what I mean.

El'endia Starman

func:function_name[named_args](args){code}

4:52 AM

Anyways I gotta go. If you get some codez you should set up a C9 VM so people can collaborate

El'endia Starman

Hmm, not a bad idea. You'd have to walk me through that though.

Thanks for the input! :)

Anonymous

5:15 AM

What is this all about

El'endia Starman

5:27 AM

@Mego I'm designing a new language, an actual language, that I hope to use in the same situations as Python and other languages. It will also have a golfy mode or version where the function names become one or two bytes (and probably far looser parsing rules too).

Draft of goals:

yesterday, by El'endia Starman

- get rid of fluff where possible
- make it a lot easier to use common patterns (like nested loops)
- when feasible, make it readable/understandable
- flexibility with sensibility
- practicality-oriented (not simple/elegant like Lisp nor overly complex like C++ or Perl)

Anonymous

So basically the opposite of Python

El'endia Starman

Don't you dare smear the glorious Python.

Python did well in making it easier to write and read the language.

I mean, stuff like and...

I'll definitely be borrowing several features from Python.

There will be a lot of [La]TeX style too.

Anonymous

1. Python is cool with fluff if it improves readability/comprehension. "Explicit is better than implicit."
2. Ok that one is pretty Pythonic, except for the nested part - "Flat is better than nested."
3. Readability and understandability are the main goals of Python, not just "when feasible"
4. I guess sort of? But it sounds like it might go against "Explicit is better than implicit.", "There should be one-- and preferably only one --obvious way to do it.", and "In the face of ambiguity, refuse the temptation to guess."

Anonymous

I briefly entertained the idea of making a mainstream language, but then realized that Python is exactly what I want.

Anonymous

As for the cycle stuff - itertools.cycle is your jam

Anonymous

5:37 AM

cycle(cycle(0,1), cycle(2,3)) should return [0, 2, 1, 3, 0, 2, 1, 3, ...]

Anonymous

Cycle through the arguments, extracting and returning the next element in the iterable (constants should be length-1 iterables)

El'endia Starman

Maybe I should write a Zen of Pytek. :P

Anonymous

You should

Anonymous

It'll help keep you focused :P

El'endia Starman

yeah :P

A line I'd add: succinctness is power.

Also: more work for the parser and less work for the programmer is good.

El'endia Starman

6:08 AM

> [Fred Brooks] wrote that programmers seemed to generate about the same amount of code per day regardless of the language.

Anonymous

Yep, part of my software engineering course was learning about The Mythical Man Month

El'endia Starman

I have yet to read that book. I should put it on my wish list.

That's why I'm willing to sacrifice some plain readability for conciseness and sheer flexibility.

\nestedLoops in particular would scratch that particular itch of having to loop through a 2D array with a pair of nested loops.

Oh, and the slight verbosity of for i in range(S): sometimes annoys me. Especially when I want to loop through a list, but by index, not element. I can do for i in range(len(S)): or for i,v in enumerate(S), both of which are a bit verbose.

The irony is that the plethora of built-in functions are a bit verbose, but I do plan on making up for that by making them really powerful and combine-able.

Anonymous

Ultimate synergy: every function supports variable arguments. One data type for everything, so all functions take the same type of argument(s) and give the same type of return. The output of any function can be the input to any other function.

El'endia Starman

...that sounds like Lisp. :P

Anonymous

6:24 AM

Yeah kinda :P

Anonymous

That's one of the things I like about Lisp, though

Anonymous

It's one of Lisp's most powerful features

El'endia Starman

aye

But you have to write a lot more code, I think.

I wouldn't know for sure because I've never used Lisp.

Anonymous

Writing more code in Lisp is more due to the syntax than the type design

El'endia Starman

That makes sense.

El'endia Starman

6:43 AM

That said, I do foresee functions being very important in Pytek.

And the paradigm will be somewhat different. Dunno if it'll be a common one.

Worth thinking about: Spartan programming.

Hah, the example for "In the face of ambiguity, resist the temptation to guess" here is 1 + '1'.

yesterday, by El'endia Starman

"5"+5 should throw ambiguity warning and return 10

There have been multiple times where I thought a number was an integer but was in fact a string. Irked me a little bit every time.

And along the same lines, this:

>>> ' '.join([1,2,3,4,5])
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in <module>
    ' '.join([1,2,3,4,5])
TypeError: sequence item 0: expected str instance, int found
>>> ' '.join(map(str,[1,2,3,4,5]))
'1 2 3 4 5'

Annoys me every time.

>>> "hello"+5
Traceback (most recent call last):
  File "<pyshell#9>", line 1, in <module>
    "hello"+5
TypeError: Can't convert 'int' object to str implicitly

And this.

What would be great is if I could have another operator for concatenating strings and + always coerces strings to ints when possible.

Anonymous

7:08 AM

You could go VB style

Anonymous

& is concat for strings

Anonymous

@El'endiaStarman Link rot got to that page :(

El'endia Starman

Heh, I didn't check any of the links on the page.

Anonymous

3/3 are borked

El'endia Starman

@Mego hmmm, yeah, I could do that

I was deliberating on whether to use & and | for and and or, or use the words like Python does.

Anonymous

7:16 AM

Now all we need is a post from Jeff about link rot from < 2008

Anonymous

Both

Anonymous

But don't do what Python does, where they are almost the same but slightly different

El'endia Starman

Yeah, they're bitwise operators in Python if I recall correctly.

Anonymous

Yep

Anonymous

Be like C

Anonymous

7:17 AM

&& == and, || == or

El'endia Starman

But if & is and and & is string concatenation too...

Anonymous

& would be bitwise and with 2 integer (or integer iterable) operands

Anonymous

And string concatenation if one operator is a string

Anonymous

Are you trying to make ints and digit-strings interchangeable?

El'endia Starman

Not exactly, more like trying to reduce frustrations from expecting a number to be in a number type.

Anonymous

7:20 AM

Then don't have number types

Anonymous

Everything is a string

El'endia Starman

pffft ha yeah right

Anonymous

"12"+"34" == "46", "12"&"34" == "1234" (or whatever operator you choose to represent concatenation)

Anonymous

Relevant: cplusplus.com/reference/ciso646

El'endia Starman

huh, cool

Idea: use @ like TI-BASIC's Ans or Python IDLE's _.

And again, you can attach a number to it to specify how far back you want to go.

>>> 2+2
4
>>> @
4
>>> 3+5
8
>>> 5+8
13
>>> @1&" "&@2
13 8

Anonymous

7:33 AM

That would be useful in a REPL environment, but almost certainly pointless otherwise

El'endia Starman

Hmm, you might be right on that.

Anonymous

Also keeping a list of all previous results would be sloooooooooooooooow and a memory hog

Anonymous

What even would be the point in a non-REPL environment? Either you care about the return value, so you stored it in a variable, or you don't, and you would never fetch it

El'endia Starman

hmm

It'd be useful for golfing? :P

But that's an afterthought, so yeah, I probably won't do that.

I'll include \ans anyway.

Okay, bedtime for me.

Thanks for the discussion! :)

Anonymous

8:04 AM

Anytime :)

5:47 PM

@El'endiaStarman This is what Perl does. . concats strings, + coerces strings to ints.

Although there is no real difference between strings that contain numbers and numbers

El'endia Starman

Cool, there's precedent! Ewww Perl. :P

Also what will a function definition look like?

El'endia Starman

13 hours ago, by El'endia Starman

func:function_name[named_args](args){code}

^ Current plan.

I like that.

El'endia Starman

Also, another line of the Zen of Pytek: Tradition is suspect, but keep it when it's the best choice or idea.

6:01 PM

Make sure you have an annotation of some sort that lets a function be eager evaluated

El'endia Starman

hmm

What would be the benefit?

Stuff with sockets.

El'endia Starman

I know of one: time-sensitive situations.

If you lazy evaluate socket stuff you risk getting hung up on

El'endia Starman

right

Perhaps an asterisk at the end of the name?

function_name*(args)

Or an exclamation point, maybe?

function_name!(args)

6:06 PM

I like !

uh-oh there's something named pytek:

pypi.python.org/pypi/pytek/1.1.1.0-r5

> PyTek provides a python API for interacting with Tektronix oscilloscopes over a serial interface.

El'endia Starman

ಠ_ಠ

I'm thinking about keeping the name anyway. It's not like there are no name collisions ever.

ew the guy uses bitbucket

So what's this lang about?

El'endia Starman

I really need to write one message to answer that question and pin it.

^

El'endia Starman

6:15 PM

Pytek is intended to be an actual, mainstream language that aims to reduce the amount of programmer work, largely by identifying and leveraging common patterns, such as nested loops. There are two overarching goals: 1) make the computer do as much of the programming work as possible, and 2) succinctness is power - there are great benefits to saying much with few words.

9

That sounds like a great idea. Will it have the spaceship operator <=>?

El'endia Starman

Oh, another thing I forgot to mention: \breakIf will be a thing and will let you exit an if conditional from the inside.

@ETHproductions What would be its use?

Cause the TIE Fighter sound to play over the speakers?

That'd be a fun Easter egg. :P

<=> is like compareTo. It returns -1, 0 or 1 depending on less than equal or greater than

@El'endiaStarman It would have the same order-of-operations level as < > <= >= ==; it compares two operands and return a<b?-1:a>b?1:0. It's a feature in PHP and Ruby, I believe

El'endia Starman

Ooooh, I like that.

6:22 PM

One of a<=>0 or 0<=>a would be (practically) the same as sign(a)

Is there an up-to-date version of the spec somewhere online?

El'endia Starman

Nope.

I've done no coding yet.

I know no coding is done, but it would be nice to look at what's planned when you get a chance.

@ETHproductions just look at the transcript :P

El'endia Starman

Well, yeah, ^ that :P

I'm hashing out the spec in this room.

Oh, alrighty then. I'll do that later

El'endia Starman

6:24 PM

I do plan on making a web page to lay out the spec more thoroughly and in an organized manner.

Still thinking on how best to do that, because I want both Markdown and LaTeX (MathML could suffice, I suppose), and Stackedit, while awesome, doesn't really let me share what I write with other people.

That said, @ETH, PyAcidic Musings was the first thing I wrote on this language.

@El'endiaStarman So blocks are going to be your approach to anonymous functions?

El'endia Starman

hmm

Not sure how those fit into the state of the language now.

I wrote out some basic spec for a useful-ish language recently (well, just the operators, I really like operators)

El'endia Starman

I welcome your ideas. :)

Thanks :) I'll look through them later, I don't have my notebook with me right now.

« first day (1 day earlier) ← previous day next day → last day (659 days later) »

Transcript for

Feb '169

Pytek

Discussion for this in-development language

awsum language-design poltergeists pytek

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile