Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:11
    trocher edited #3175
  • 08:28
    pcaversaccio edited #3173
  • 08:25
    trocher opened #3175
  • 02:20
    codecov-commenter commented #3174
  • 02:19
    codecov-commenter commented #3174
  • 02:19
    codecov-commenter commented #3174
  • 02:18
    codecov-commenter commented #3174
  • 02:18
    codecov-commenter commented #3174
  • 02:18
    codecov-commenter commented #3174
  • 02:17
    codecov-commenter commented #3174
  • 02:15
    codecov-commenter commented #3174
  • 02:14
    codecov-commenter commented #3174
  • 02:14
    codecov-commenter commented #3174
  • 02:14
    codecov-commenter commented #3174
  • 02:14
    codecov-commenter commented #3174
  • 02:14
    codecov-commenter commented #3174
  • 02:13
    codecov-commenter commented #3174
  • 02:13
    codecov-commenter commented #3174
  • 02:13
    codecov-commenter commented #3174
  • 02:12
    codecov-commenter commented #3174
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] basically all of the on-chain stuff
Lachlan Ford
@fordacious
@vbuterin thanks
El De-dog-lo
@fubuloubu
That sort of brings up a good point, Viper itself is unaudited security-wise (I believe), but I am sure you have done very extensive testing for Casper. Does that create any kind of roadblock to Casper, the fact that we haven't fully rolled out a beta or done an audit yet?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] IMO this is one of the reasons why we should feature-freeze viper ASAP and just focus on hardening for a while
El De-dog-lo
@fubuloubu
Yeah, I would tend to agree if it is being used for such mission critical code.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] the simple fact that casper can be written in viper already implies that it was >90% close to feature complete when that happened
El De-dog-lo
@fubuloubu
I've been talking with David a bit about an alternative method of architecting the parser, in order to make it new features easier and cleaner to implement
Totally, agree. Perhaps a sign that we should push to a beta
I dubbed it the Lego™ blocks method lol
El De-dog-lo
@fubuloubu
On top of simplifying compiler code, it could also enable extensions that are clearer and more user friendly e.g. constructing new types that represent common patterns that are typically used in contracts
We can discuss the idea next week if you are interested in it for the next phase of Viper, which comes after this feature freeze for release of Casper. Gives us some time for this re-architecting if we all agree it's a good plan.
Dishendra
@Dishendramishra
hi all, So why we have changed name to vyper from viper? searching vyper on google show this link at first index https://vyper.io/
El De-dog-lo
@fubuloubu
d'oh! we never checked website urls!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] at least that has nothing to do with programming langs
El De-dog-lo
@fubuloubu
we were asked to change our name because of a conflict with another swiss-based institution that had a programming language called Viper with a few years of pedigree
Holger Drewes
@holgerd77
Also think this should be hopefully ok
Dishendra
@Dishendramishra
bank: public({
    account_balance: num,
    person: bytes32
    }[num])

@public
@payable
def transfer(sender_accno: num, reciever_accno: num, amount: num):
    if self.bank[sender_accno].account_balance >= amount:
               pass

throwing error "AttributeError: 'Name' object has no attribute 'value'
" at this line

if self.bank[sender_accno].account_balance >= amount:

account_balance and amount are both of same type 'num' and it does support >= comparison operator. So, what's wrong with that?

DavidKnott
@DavidKnott
@Dishendramishra I just ran the code you posted and it worked for me. Can you please make an issue specifying the file / line number of the error and how you installed Vyper so we can dig into your issue further?
Neil Henegan
@neilh
I'd like to use vyper in a production app, is there an ETA on a stable version?
Charles Cooper
@charles-cooper
hello! what is the best way for newcomers to contribute?
El De-dog-lo
@fubuloubu
  1. Reviewing docs
  1. Checking test case functional coverage and fixing coverage issues
Then playing around and letting us know if there uncovered errors, or errors that do not give traces that make sense to you
@neilh safest bet is mid year, although Casper will be the first production usage of Viper courtesy of @vbuterin
@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
El De-dog-lo
@fubuloubu
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?