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

doc strings #25

Open
MadcapJake opened this issue Jul 26, 2015 · 10 comments
Open

doc strings #25

MadcapJake opened this issue Jul 26, 2015 · 10 comments

Comments

@MadcapJake
Copy link

Support functions having a doc string immediately following their definition. e.g.,

func = x ->
   """
   This function adds a number to itself
   """
   x + x

func.doc-string() ;; => "This function adds a number to itself"

This could be utilized in editor tooling and in the repl.

@davej
Copy link

davej commented Jul 26, 2015

Is there a reason to make it a function call? As opposed to just func.doc-string?

@MadcapJake
Copy link
Author

No, you're right. Also do you think it should be __doc__ like python?

@davej
Copy link

davej commented Jul 26, 2015

I don't know really, I don't think there's any precedence for marking 'magic' properties in Earl Grey. I don't particularly like the aesthetics of dunder variables but they should probably be marked somehow so they are distinguishable from normal properties.

@MadcapJake
Copy link
Author

Functions currently have these:

__defineGetter__ 
__defineSetter__
__lookupGetter__ 
__lookupSetter__
__proto__

So I think the precedent is there.

@davej
Copy link

davej commented Jul 26, 2015

But they are javascript properties and not Earl Grey specific.

@MadcapJake
Copy link
Author

Yeah, but maybe since docs would only be used in tooling, this might be a time to use the dunder style. I honestly don't mind either way how it's named though, just thought it might be a valid situation for that naming scheme.

@breuleux
Copy link
Owner

With Symbol, there is no reason to have magic properties that are strings. The documention could be accessed as fn[Symbol.doc], for example. To make it easier, a builtin help(fn) or doc(fn) function could be added.

@davej
Copy link

davej commented Jul 26, 2015

If there was a designated format for these docstrings. Then you could probably even parse the types for argument and return values and write out some typescript.

(Perhaps I've drank too much coffee)

@breuleux
Copy link
Owner

I'd rather not parse types from docstrings. I'd rather have something like [-> String?] fn(String? x, String? y) = ..., or maybe

typeof fn = {String?, String?} -> String?
fn(x, y) = ...

@MadcapJake
Copy link
Author

That's be really cool!

But also as far as docstrings, leaving them without a format means that one could use JSDoc format, markdown, 💡 EGDoc(Quaint-based perhaps?), bare text, or something else!

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

No branches or pull requests

3 participants