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 overloaded print functions for debugging #167

Open
porky11 opened this issue Jan 10, 2017 · 7 comments
Open

add overloaded print functions for debugging #167

porky11 opened this issue Jan 10, 2017 · 7 comments

Comments

@porky11
Copy link
Contributor

porky11 commented Jan 10, 2017

I'm currently writing this, it already seems nice
Here some example usage
https://github.com/porky11/dale/blob/print/modules/print.dt#L88
it's similar to c++ stream operator<< but looks better, and also returns the printed value like lisp (this will be done as macro, so this won't become inefficient)

@BitPuffin
Copy link

Would also be cool if there was a type-safe format macro like the one in Rust for example. Or how printf works in OCaml.

@porky11
Copy link
Contributor Author

porky11 commented Apr 7, 2017

Yes, rusts print! and println! macros also look good for printing. I think, selecting, how something is printed, should be dispatched at compiletime, not at runtime like in c.
I don't know about printf in OCaml

@BitPuffin
Copy link

If I remember correctly. Printf in ocaml is much like printf or like rusts print macros. Except that I think it's built in to the compiler to type check at compile time (and probably more optimized than C printf). In dale we should be able to implement this as a library instead of in the compiler.

@porky11
Copy link
Contributor Author

porky11 commented Apr 7, 2017

In rust this is implemented using the traits for normal printing and debug printing. In dale implementing a concept for printing would be similar, but since concepts cannot be implemented automatically (yet?), so something like my version is more usable, maybe with some compile time checking for existance.
Why should a format string be used? Isn't (print "Hi, my name is " name " and I'm " years " years old") easier to read and write than (print "Hi, my name is ~a and I'm ~a years old" name years). In the last case, it's easier to see all arguments, that may be mutable, but they may also be constants.

@porky11 porky11 closed this as completed Apr 7, 2017
@BitPuffin
Copy link

Format strings are nice sometimes. For example if the variable names are very long it is easier to see the format of the string to get a sense of what it will look like. And then you just gotta make sure the order is right etc. But yeah. I think both should be offered.

@porky11 porky11 reopened this Apr 8, 2017
@porky11
Copy link
Contributor Author

porky11 commented Apr 8, 2017

something like (print "Hi, my name is {name} and I'm {years} years old") would also be possible (I think, ren'py uses something like this). You even could have reader macros which expand #"String {Var}" to (string-append "String " var).

@BitPuffin
Copy link

Yeah I'm all for that kind of feature. But still it doesn't solve the issue that the variable names that you are interpolating might be really long. So you might wanna have the option of using safe format strings.

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

2 participants