/dpt/ - Daily Parrot Thread

What are you mimicking today, Sup Forums?

Previous thread:

a good programmer who has confidence in himself.

What's the ideal language

>void
>_Bool
>char
>int
>long int
>long long int
>unsigned char
>unsigned int
>unsigned long int
>unsigned long long int
>void *
>_Bool *
>char *
>int *
>long int *
>long long int *
>unsigned char *
>unsigned int *
>unsigned long int *
>unsigned long long int *
should have been
>u0
>u1
>i8
>i16
>i32
>i64
>u8
>u16
>u32
>u64
>u0*
>u1*
>i8*
>i16*
>i32*
>i64*
>u8*
>u16*
>u32*
>u64*
and uppercase reserved for typedefs

What the fuck were they thinking, especially with _Bool?

Idris if it were fast.

heh.

What is the most precise way of timing shit, is std::chrono::high_resolution_clock() fresh?

Common lisp

Java

Agda surely

Not ideal, but the best one ever created.

>u1 for bool
kys

agda does some wonky things and idris is comfy.

It is unsigned, and has 1 bit of value. That we don't have a way to force/unforce packing is of course a shame, but not a fault of the type names.

>that feel when you fucked up logic of the application, and had to duplicate ~100 lines of code.

Its going right into production anyway.

>no strings
>no enums
>no mixins
>no modules
>no ufcs
>no ctfe
>no lambdas
>no closures
>no properties
>no uda's
>no templates
>no ranges
>no slices
>no lazy
>no foreach

Need i go on?
>inb4 "all bloat"

What do you guys think

#include
#include

int main()
{
short s = 0;
char* str = "Hello World!\n";

for(int i = 0; i < strlen(str); ++i){
s = (short)str[i];

printf("%s", &s);
}

return 0;
}

Ideal language, shitty community.

It's a Boolean value, not an unsigned 1-bit number. Why would it not be marked with bool

Ideal core language, wonky syntax, great but way too small community.

>ideal language
Not yet.

>POSIX.1 defines seconds since the Epoch using a formula that approximates the number of seconds between a specified time and the Epoch. ... This value is not the same as the actual number of seconds between the time and the Epoch, because of leap seconds ... see POSIX.1-2008 Rationale A.4.15 for further rationale.

So what do we find in POSIX.1-2008 Rationale A.4.15?
Nothing.

>A.4.15 Scheduling Policy
>There is no additional rationale provided for this section.

However,

>A.4.16 Seconds Since the Epoch
>Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences.

What the fuck? Are they trying to trick me? Is this the power of GNU?

So is pony a meme or not? I have difficulty taking it seriously given its name.

BC and the syntax is not ideal in any way.
Solid language bogged down by terrible syntax.

C++

>open-source
If a new programming language is not free software or at least open source then something is wrong.
>object-oriented
Gross.
>actor-model
Gross.
>capabilities-secure
Sounds interesting.
>high-performance
Relative to what?

Why couldn't they have called it something like 'Equine' or 'Mare'?

C was designed to allow for non 8-bit byte architectures, so naming the standard integer would be inappropriate.
>What the fuck were they thinking, especially with _Bool?
The C standard reserves all identifiers with a leading underscore and capital letter or two leading underscores.
So when they typically add a new keyword, they will use a reserved identifier to not break any existing code, and provide a convenience macro (bool from stdbool.h).

Pretty sure they said in a talk they plan to FOSS it Soon™.
>Relative to what?
"It's faster than Java, but still not comparable to C/++"

And i think it's a nice paradigm difference from the usual C-like. They just really need to clean up things.

actor Main
new create(env: Env) =>
env.out.print("Hello, world!")

The only thing I'd like to have added to Rust is trait members and maybe function overloading. Lately we got generators/coroutines which was the biggest wish for me I guess.

I need to create some kind of pattern to be able to translate objects to different type without changing and knowing its implementation just know that every type have two pointers to same type and one int member.

Imagine someone has following code:

struct SomeonesNode
{
SomeonesNode* previous;
SomeonesNode* next;
int key;
double weight;
}

and someone else has code:

class AnotherOne
{
AnotherOne* prev;
AnotherOne* next;
int key;
}

And I want to translate/cast these objects to

class Node
{
Node* prev;
Node* next;
int key;
}

I want to give them possibility tu run my function (myFunction(Node* node)) on theirs own implementation without need to change code.
How can I achieve this?

I could require to implement theirs own casting fe.

class Node
{
Node(YourObject& yourobject) {
prev = new Node(yourobject);
next = new Node(yourobject);
key = youobject.getKkey;
}
}

And additional I need to prevent looping when objects are linked in circular way.

Is this a good approach? Any better ideas?

>coroutines
That's great news.

My biggest complaint right now is the lack of full, real HKTs.

also, the whole name is a dumb joke:

>Back in the flight sim days, when I would make my friends groan by telling them yet again about all the things I was going to do when I wrote a programming language, one of the people I would tell was Nathan Mehl. And one time, when I gave him yet another laundry list, he said: “yeah, and I want a pony”.

>no strings
Wrong, there is char* which provides any sane man's idea of a string, that is a null terminated string, as used in other languages which "implement" strings such as perl. If you need byte strings the C99 VLA feature together with a struct can easily implement it, as is done in several libraries however this is an edge case which the majority of users have no use or desire for.
>no enums
What the fuck are you talking about?
C99 6.2.5.16
>An enumeration comprises a set of named integer constant values. Each distinct
>enumeration constitutes a different enumerated type.

>no mixins
Because it's not object-oriented.
>no ufcs
This does seem cool, having functions create file descriptors for write() sure would be something, instead of having to define your own wrapper like netwrite() when writing e.g a web server with dynamic application support.
>no ctfe
Macros, const attribute.
>lambdas
Function pointers.
>closures
Arrays of function pointers.
All the others are bloat, yes.

#define true 1
#define false 0

Otherwise using it for multiplication would feel unclean and like utter nonsense.

>>lambdas
>Function pointers.
>>closures
>Arrays of function pointers.

>>Ideal language, shitty community.
>Worst language
>node.js community

>Wrong, there is char* which provides any sane man's idea of a string, that is a null terminated string
I'm too scared to read the rest of your post now. Surely nobody's this delusional?

the ultimate enlightenment: realizing all monads are continuations

the enum was a mistake.
>macros
>function*
>function*[]
shit.

>UDAs
>templates
>range / slices
>lazy
>mixins
>modules

>bloat
Kill yourself m8

Well, dividing them all by 8 would be reasonable then.
_Bool is still ugly as shit, they could have went with boolean and created an alias for that.

All useful monads are either free or better done with linear types.

>Well, dividing them all by 8 would be reasonable then.
No. That's stupid.
>boolean
That would undoubtedly have broke existing code.
>created an alias for that
bool is the fucking alias. If you want to use bool , include stdbool.h. If you don't include it, don't worry about it.

Never mind, I misunderstood closures. They are even worse than I thought, and not suitable for C. Lambdas are function pointers with another syntax, yes.

They created an alias for _Bool you idiot. stdbool.h. Wew. So hard.

>not suitable for C
Because it lacks generics? Languages with generics like C++ or Rust can use closures with zero overhead (because there's no indirection).

>Lambdas are function pointers with another syntax, yes.
Function pointers are one way of representing closures (well, you also need to capture free variables). Lambdas are not function pointers, lambdas are anonymous functions which may or may not be closures (but often are).

false

What would
auto thing = [ 20, 1, 11, 300, -2 ].filter!(num => num > 10);


look like in C with a function pointer?

For example, it's what perl does. For anything else, there is the mem* family of functions.
And not a single argument.
Defining bool as an alias for boolean in stdbool.h, I mean.
There are still other names to pick for it.
It is not suitable for C as it is an incredible amount of bloat. Longjmp and inline assembly to put the registers somewhere works acceptable, but it's still a horrible idea- pointers will fuck you up
Lambdas are anonymous functions, which are syntactic sugar for function pointers. You can pass them in, return them, etc.
Why don't you explain what the code does first?

>I can't fathom how first class functions work without pointers

>Why don't you explain what the code does first?
literally just filters the numbers in the array that are greater than 10.
filter! being a template instantiation.

Name one.

Huh? We can hide them behind typedefs, but that's useless.
You would pass in a function pointer to filter!().

Now what about if 10 got changed to 10.9?

It's quite rare that you actually need to compile a subroutine that could work for absolutely any function (in which case you use a function pointer) as opposed to inlining the higher order function and the function argument. No indirection needed, and this is expressed directly with monomorphized generics.

We would change the function, or have it take 10 as an argument.
Any modern compiler does this for you.

If the code itself doesn't concern function pointers but instead uses generics, you can just pass everything by value and it's a lot nicer.

could you show me exactly how that'd look?
How would you handle if 11 got changed to 11.1?
I'm not convinced the C version wouldn't be a tedious mess, but you'll call lambda's bloat.

Generics for what? Weren't you talking about the lambda?
You would have a function called greater(x, y), which would return 1 if x > y and 0 if x < y. You could also hardcode 11 into the function and change it there.
Changing 11 (int) to 11 (int) is no difference. Changing 11.0 (float) to 11.1 (float) is a 1 character change.
Changing 11 (int) to 11.1 (float) is a 6 character change.

>Generics for what? Weren't you talking about the lambda?
Yes.

>You would have a function called greater(x, y)
So how do you do this with just a function pointer?
filter(x => greater(x, 10))

>You could also hardcode 11 into the function
ah yes, the sure sign of good code.

Is there some function like memcpy which is guaranteed to be optimized and not have UB?
as in
char[] a = "abcdefghi";
memcpy(a+1, a, 8);
// a == "aaaaaaaa";

I don't understand what you're trying to convey here.
Yeah, something like that. We weren't discussing the existence of .filter().
In some cases it, coupled with a #define or just a comment, makes perfect sense, yes.

>I don't understand what you're trying to convey here.
You say closures aren't suitable for C, I say that's just because it doesn't have generics.

memmove

Closures need you to copy the stack and dump it somewhere, not suitable, no.

Generics were a mistake.
If you don't know which data type you're going to store, you've done your analysis wrong.

...

Memmove does the opposite of what I want, it would give me "aabcdefgh".

>still no simple demonstration of a simple filter """"""""""""""""""lambda"""""""""""""""""""""" in C

>Closures need you to copy the stack and dump it somewhere
Are you somehow confusing closures with continuations? You only close over the variables you need to. C doesn't have closures because closures are incoherent outside of garbage collected languages. t. C++ with its weird "closures."


So you want the garbage data of "aaaaaa" or if you did, a+2, a, you would want "abababab"?? You're going to have to dip into assembly for that retarded behavior.

What does a function of type forall a b c. (b -> c) -> (a -> b) -> a -> c do?

What does a function of type (String -> Int) -> (Double -> String) -> Double -> Int do?

Why would this assignment produce this garbage? They are both std::string

>C doesn't have closures because closures are incoherent outside of garbage collected languages. t. C++ with its weird "closures."

Gofags everyone

In Py3, assuming the sys module has been imported, why would this:

x = input("State thy name. ")
print("Greetings, " + x + ".")

be preferable to this?:
print("Yo homie, whas'yo name?")
z = sys.stdin.readline()
print("Sup, ", z)


I'm not sure how to punctuate the end of the second example either. My attempts at doing so resulted in a newline being created, and the period ending up there.

>HKT
Could you explain what advantage would it give to Rust?
I can't find anything specific and many of HKT features can be archived in Rust.

go away ekmett

No, as C does not have filter. If it did, we could just do something like
filter(array, greater, 10);

>Are you somehow confusing closures with continuations?
Entirely possible.
>So you want the garbage data of "aaaaaa" or if you did, a+2, a, you would want "abababab"?
Exactly.
>You're going to have to dip into assembly for that retarded behavior.
Perfectly sane behavior. It copies from src to dest, since dest happens to be located inside src src happens to mutate during the copying, but this is not the function's fault. The function copies from src to dest, and you have the same problem with memcpy if another thread would suddenly start copying into src.
How would assembly help me? I can just write a function
void sanememcpy(void* dest, const void* src, size_t n)
{
void* stop = (void*) (((intptr_t) src)+n)
for (; src < stop; src++ = dest++};
}

Which does what I want.

In a good FP each arg can be named for even better context.
but why don't you paste the whole thing seeing as you're purposely leaving out the names.

But you said it's just a function pointer, so show me how simple it is.

Not him, and it's not full HKTs, but generic associated types are extremely useful. For instance:
trait Foo {
type Bar Bar

filter(array, greater, 10);

That's how, provided C would have filter().

The point is that the generic type of the first function tells you exactly what it does. You don't need to know what the arguments are named (and in any case, argument names can lie).

The second function could do any number of things.

Consider a simpler example. forall a. a -> a and Double -> Double.

Are you a rustlet? Because your "closures" are shit too.
>error: closure may outlive the current function, but it borrows `x`, which is owned by the current function [E0373]
AHAHAHA

Please tell me why that shouldn't be an error. If you need it to not be an error, you move the captured variables into the closure.

Surely the type parameter of Monad should be M? Something like:

trait Monad : Applicative {
fn return(a: A): M
fn bind(fa: M, f: A -> M): M
}

The main advantage and disadvantage of HKT's when you already have Rust's power level is stronger free theorems.

I think introducing some level of dependent types would be much more useful for Rust than HKT's desu. You can express functors/applicative/monads and traversable in Rust without HKT's. But dependent types on the other hand enable things like trait implementations for raw foxed-length arrays of any size, which is much more useful.

If HKT's get in the way of dependent types and type inference, then dump them imho.

Completely agree. I suspect HKTs are easier to add to Rust than a solid implementation of dependent types, maybe I'm wrong though.

Rust's traits have an implicit type parameter Self which is the type of the implementor. What Rust would need to have HKTs as opposed to just generic associated types would be the ability to specify the arity of Self for a trait and then some kind of type level lambda.

>If HKT's get in the way of dependent types and type inference, then dump them imho.
HKTs don't get in the way of type inference. Dependent types do.

Should i learn Rust or sepples? What are the pros and cons of each?

That's not what i asked.
You can't leave the answer half-finished, which proves my point is that C is shit.

Oh, I think I understand. So instead of M in the trait body there would be Self?

Yes.

>Should i learn Rust or sepples?
neither
>pro's : libraries i guess
>:: too many

>array indexing starts at 0

These aren't "arg names" but type-var names, and yes you can name them anything you want, and yes they're usually just abstract symbols akin to foo and bar because they occur in usually "purely symbolic" (not *specific* or specialized) simple data-structure transformation functions

Functor and Monad can be implemented easily like this:

trait Functor {
type Item;

fn map(self, f: impl Fn(Self::Item) -> U::Item) -> U;
}

trait Monad {
type Item;

fn puref(Self::Item) -> Self;
fn bind(self,impl Fn(Self::Item) -> U ) -> U
}


This implementation is actually much better than Haskell's typeclasses, since you can define (mathematical) functors between any pair of types, not just from a given type to a "container" of such types. What you give up is free theorems so that you actually have to prove a few extra laws.

The problem is that most of the stuff that HKT's are useful for in Haskell (monadic things like lists, parsers, futures, exceptions as sum types) would not apply as easily in Rust. For instance, in Rust, there are seperate types for each iterator combinator (.map returns Map, .filter returns Filter, etc.). When Haskell folks beg for these features in Rust, it just comes off to me like them wanting their favorite features in every language; there is no real practical need for the kind of Monad representation you want.

However, HTKs would still be nice for abstraction over pointer types and to make functions parametric over mutability. Also, value kinds would be really nice to clean up the messy slice implementation.

This isn't to say that we don't need better monad support. The tokio concurrency library, and the pervasiveness of Result shows that we really DO need some sort of monad abstraction. Manually writing .and_then everywhere is very ugly. Perhaps they can look at OCaml, which provides preprocessor extensions that just transform "let%bind x = e in b" into "bind e ~f:(fn x -> b)". However, there are still problems; closures have specific semantics in Rust that are not nearly as free as closures in GC'd languages, which occasionally bites you in the ass when doing closure-heavy stuff -- especially when threading stuff like tokio monads. If the presence of closures were sugared away, then you would have to diagnosing borrow checking problems in closures that are completely implicit. Not something I would like to spend my time on.
It's not an easy problem. I'd love to hear some of these points addressed

...

Why is the /dpt/ on wizchan so much better than here? Is it really true you need autism to be a good programmer?

>go there
>literally the same type of posts as /dpt/ only with more Sup Forums kiddy questions
alri /r9k/