Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:13
    pcaversaccio commented #3114
  • 15:12
    pcaversaccio commented #3114
  • 15:09
    pcaversaccio commented #3114
  • 14:41
    pcaversaccio edited #3116
  • 11:06
    pcaversaccio edited #3116
  • 11:06
    pcaversaccio edited #3116
  • 11:05
    pcaversaccio edited #3116
  • 11:04
    pcaversaccio opened #3116
  • Oct 03 14:50
    tserg synchronize #3112
  • Oct 03 12:53
    benber86 edited #3115
  • Oct 03 12:53
    benber86 opened #3115
  • Oct 03 10:41
    tserg synchronize #3112
  • Oct 03 03:44
    z80dev commented #2994
  • Oct 03 03:44
    z80dev commented #2994
  • Oct 03 03:43
    z80dev commented #2994
  • Oct 03 00:29
    zcor opened #3114
  • Oct 02 17:58
    tserg synchronize #3112
  • Oct 02 17:54
    tserg synchronize #3112
  • Sep 30 18:41
    charles-cooper labeled #3070
  • Sep 30 18:41
    charles-cooper labeled #3070
El De-dog-lo
@fubuloubu
@charles-cooper you could also help in reviewing past issues and helping to organize those into must-have or nice-to-have buckets, so we know what must be in v1.0
This is more me speaking out loud btw haha
Charles Cooper
@charles-cooper
i was going through the issues earlier and as an outsider it's not that clear what's super important and what is not. like i can guess based on the design goals but that's more my opinion ;)
for instance, it seems a lot of the open issues result from viper being dynamically executed and typed. which suggests an entire redesign using static type inference / pure expressions, but of course that could be at philosophic odds with the current status of the project
El De-dog-lo
@fubuloubu
We'll, sorting them according to your own understanding of the philosophy of Viper is a useful endeavour, helping us make sure we're not being inconsistent in response to some issue that someone brought up
I know there is probably a huge difference between my responses a few months ago and my responses last week, would be great to get a second eye on them with a person who had a strong understanding of language design.
Basically, opinions are very important and evolved over the course of the past few months as we all have learned more
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] what do you mean by dynamically executed and typed?
[Vitalik Buterin] types are all determined at compile time
El De-dog-lo
@fubuloubu
As a side note, I consider viper statically typed. How do you think it is not?
I also don't know what "dynamically executed" means considering this is a compiled langauge that compiled to bytecode
@charles-cooper would love to understand your perspective
Charles Cooper
@charles-cooper

Hi! I was using 'dynamic' in a very fast and loose sense based on the issues I read and vyper's surface similarity to python. But after reading more of the vyper source and testing it out, I found that vyper is much more static than I originally thought.

For instance, based on the following issue ethereum/vyper#582, it looked like [ 1, 2.0, 3 ] was valid vyper. (allowing mixed type lists would result in a dynamically typed language because you can't determine the list element types at compile time). When i went to test it out though, and reading through this channel's history, it looks like mixed typed lists don't compile.

Another thing I noticed was about the semantics of None. It seems that None inhabits every type - but at least you can't have a None with underspecified type (e.g. foo = None is an invalid declaration of foo). Reading through some IR output though it seems None is just an alias for 0, which seems typesafe but obfuscating.

My comment about dynamic execution was based on ethereum/vyper#590, as well as vyper's surface similarity to python (which allows code rewriting at runtime). But I see after playing with vyper some more that block-local functions (or really any other mechanism which could result in contract-local looping/recursion) are disallowed. This is good because it improves the ability to statically trace execution! Now correct me if I'm wrong here but does this mean vyper is not Turing complete? Or is there still a back door to recursion through remote calls via raw_call?

So with the caveat that control flow is a very tricky design area, I think static analysis would be improved further though by requiring all if statements to have both branches and disallowing short-circuiting / remote calls except in very explicit contexts. For instance in Haskell, 'short-circuiting' basically requires a monadic context in order to happen. I think having a limited effects system (which decorators already provide some mileage towards) could help solve a lot of these problems.

Charles Cooper
@charles-cooper

For instance, I was thinking about ethereum/vyper#590 and it seems that the issue is stemming from having two separate 'effect systems' for functions-which-don't-return-anything and functions-which-return-something. If they had been reified into a single type, making pass an alias for return void (and disallowing signatures like def foo(), instead requiring def foo() -> void), then of course def foo() -> num couldn't end in pass (aka return void) because that wouldn't type check.

It's just an idea - in practice it would probably be too draconian to require users to add return void everywhere, although perhaps functions could be annotated with default return values.

El De-dog-lo
@fubuloubu
Thanks for the thoughtful analysis!
I think in some of your examples, e.g. requiring both branches of if and requiring void return type could be solved by implicit assumption in an intuitive and safe way
I think adding else pass implicitly is okay from a static analysis perspective
And assuming return [void] (you can call return without any type to output) when no return exists in the function is also pretty okay
The observation that we handle some of these cases slightly differently is good feedback to take note of. I am with you on that point
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

[Vitalik Buterin] > (allowing mixed type lists would result in a dynamically typed language because you can't determine the list types at compile time)

In the [1, 2.0, 3] case, what should happen is it gets auto-casted to [1.0, 2.0, 3.0]

[Vitalik Buterin] ah I guess now it doesn't even compile
[Vitalik Buterin] > Now correct me if I'm wrong here but does this mean vyper is not Turing complete?
[Vitalik Buterin] vyper is decidable, not turing complete
Charles Cooper
@charles-cooper
@Eth-Gitter-Bridge Thanks for helping clear those up!
Charles Cooper
@charles-cooper

@fubuloubu how do you feel about forcing each branch of an if statement to have the same effect type? Take for instance the following example

def foo (x: num) : 
    if x < 2 : 
        x = 2 # modifies locally scoped variable, call it the 'locally scoped mutation effect'
    elif x < 10 : 
        self.balances[self.owner] = x # modifies contract state, call it the 'contract mutation effect'
    elif x < 15 : 
        return 1 # exits the function, call it the 'control flow effect'
    else : 
        raw_call(stuff) # calls to external address, call it the 'external call effect'
    return 0

Each branch has fundamentally different properties which you might want to segregate. If you forced each branch to have the same kind of effect, it might be easier to perform certain kinds of analysis on these blocks.

El De-dog-lo
@fubuloubu
How would you even programmatically enforce That?
Interesting idea, but along with the forcing both branches thing I think it's a little unintuitive to work like that
Although it's definitely worth considering because it also helps with auditing friendliness (at the detriment of programmer friendliness)
Charles Cooper
@charles-cooper
Well the devil's in the details but basically you assign different kinds of statements different types (aka effects) and then let the type checker sort it out
Michael Sproul
@michaelsproul
Hi all, I've written a Vyper contract which takes an argument of type decimal in its constructor, but I can't work out how the heck to pass a literal using web3.py. I've unsuccessfully tried literals of the form: 0.2, 0, "0", "0x0", 1/2... Is this not yet possible? (I found this: ethereum/EIPs#598)
(I've also tried Python's Decimal type, with no luck)
El De-dog-lo
@fubuloubu
That sounds more like a bug with web3.py then Vyper
Solidity doesn't have a working decimal type yet I don't think, so that might be why web3 doesn't implement it properly
P.S. Technically our biweekly call is in 7 mins, but I say we push that until tomorrow or Wednesday lol
Michael Sproul
@michaelsproul
Yeah, I think it's a case of the ABI for "decimal" not being set in stone. As far as I can tell, pyethereum is the only client that implements support for it, and Vyper depends on that for testing? I've posted a comment on ethereum/EIPs#598
El De-dog-lo
@fubuloubu
Ah yeah, that totally makes sense. I was looking into porting pyrthereum to web3.py, probably would've ran into that issue as I got in the weeds
william bright
@whb07
sooo errmmm ummm... guess i'll help out with guide to install viper?
im going to see if we can make it nice and neat. anyone got any suggestions on what they want to see?
i'll be destroying and spinning up ubuntu/deebian servers like no other :)
El De-dog-lo
@fubuloubu
Sounds great! Make it so!
James Ray
@jamesray1
Jacques
@jacqueswww
@here this channel will be archived soon. Please continue discussions in : https://gitter.im/ethereum/vyper
:) :snake:
James Ray
@jamesray1
:grinning: :thumbsup:
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Jarrad Hope 侯家睿] Hey guys I was wondering what peoples time estimations for Vyper beta would be? ie should we start pushing it as the language to use?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] my personal preference is we get a spec freeze ASAP (ie. days), get remaining stuff coded up (as far as I can tell, basically the extra restrictions I mentioned in the gitter channel) and then aim for audit-readiness
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Jarrad Hope 侯家睿] okay sweet
Denis Bogdanas
@denis-bogdanas
Hi guys, I'm Denis Bogdanas. Currently I'm maintaining the Viper semantics in K.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[David Knott] It converts data types uint256 => int128