Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add built-in function docs #604

Merged
merged 1 commit into from
Dec 25, 2017

Conversation

DavidKnott
Copy link
Contributor

- What I did

Created a docs page for Vipers built-in functions

- How I did it

Looked over the functions in functions.py and wrote documentation for them.

- How to verify it

Read the documentation

- Description for the changelog

None

- Cute Animal Picture

image

@fordacious fordacious mentioned this pull request Dec 24, 2017

Functions
=========
The first list dictates each argument and the second sublist lists the types allowed as input.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe consider some simple examples.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact linking to the online execution environment (compiler / remix etc...) with executable examples in context would be super useful to developers but that would require writing those examples so should be a separate task

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a fan of simple examples, down the road maybe we could have a section in examples/ dedicated to showing off specific viper functionality?

:param a: value to round down
:type a: either decimal or num

:output b: interger

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: interger -> integer

:output product: num256[2]
"""

Takes two elliptical curves and mupltiples them together.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: mupltiples -> multiplies

"""
:param a: pair to be multipled
:type a: num252[2]
:param b: pair to be multipled

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: multipled -> multiplied


def ecadd(a, b) -> product:
"""
:param a: pair to be multipled

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: multipled -> multiplied


Functions
=========
The first list dictates each argument and the second sublist lists the types allowed as input.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The type information appears to be available in the signature annotations. Would it be possible to utilize that info?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just removed this line as I think it just creates more confusion then it's worth.


def extract32(a, b, type=c) -> d:
"""
:param a: where 32 bytes are extacted from

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: extacted -> extracted

"""
Returns the length of a given list of bytes.

* **concat**
Copy link

@fordacious fordacious Dec 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

concat appears to lack the signature annotation in functions.py (Is this problematic?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's a problem, it doesn't have signature annotations because it takes a dynamic number of arguments.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought that might be the case. On inspection of the code it looks ok, as concat checks its own argument semantics.

def as_num128(a) -> b:
"""
:param a: value to turn into int128
:type a: either num, bytes32, num256, or bytes

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider specific examples as to how this transformation occurs, in order to avoid surprises and sneaky bugs for developers.


:output b: bytes
"""
**Name:** ``method_id``

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

markup

* **decimal**
::

def decimal(a) -> b:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name is different from other type conversion functions. Is this an intensional design choice?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also it doesn't seem to be included in the types.rst conversion table.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to change the name to as_decimal

:param a: value to turn into decimal
:type a: either decimal or num

:output b: decimal

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For these type conversions we should be sure to document general behavior and corner cases (e.g. underflow / overflow behavior)


:output d: bytes
"""
Takes a a list of bytes, the start bytes to take and the length to take and returns the associated chunk.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copied or referenced? (Possible source of sneaky bugs)

* **concat**
::

def concat(a, b, ...) -> c:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing documentation of variadic args here (...). We should document constraints here (e.g. concat requires two or more arguments of type byte32 or byte[])

def bytes_to_num(a) -> b:
"""
:param a: bytes to be transformed
:type a: bytes

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider documenting the behavior when arrays are length 0 if that is valid input

* **slice**
::

def slice(a, start=b, length=c) -> d:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consider documenting the behavior when the range is invalid for the given input

Copy link
Contributor

@sdtsui sdtsui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work, @fordacious!


:output d: bytes
"""
Takes a a list of bytes, the start bytes to take and the length to take and returns the associated chunk.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo:

Takes a a list of bytes

"""

Takes a function declaration and returns its method_id (used in data field to call it).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes there are two spaces between annotations, other times there are one. Intentional?

@DavidKnott
Copy link
Contributor Author

@fordacious @sdtsui Thanks a lot for the feedback, I corrected the typos and tried to make a few parts clearer. Merging this in.

@DavidKnott DavidKnott merged commit eb4b1dd into vyperlang:master Dec 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants