|
VikingofRock posted:defining a function within a function it really is weird how this relatively simplistic and easy to understand feature ended up not being more standard in mainstream languages, encourages breaking pieces of functionality apart while keeping the namespace easy to navigate
|
# ? Jun 9, 2016 12:14 |
|
|
# ? Jun 12, 2024 08:15 |
|
Cybernetic Vermin posted:it really is weird how this relatively simplistic and easy to understand feature ended up not being more standard in mainstream languages, encourages breaking pieces of functionality apart while keeping the namespace easy to navigate now imagine it in the hands of academics
|
# ? Jun 9, 2016 15:11 |
|
matlab is extremely bad
|
# ? Jun 9, 2016 15:19 |
So I've never really run into a use case for fully heterogenous lists. When do people use them? I'm assuming there must be some use case since so many weaker-typed languages tote them as features.
|
|
# ? Jun 9, 2016 16:59 |
|
Cybernetic Vermin posted:it really is weird how this relatively simplistic and easy to understand feature ended up not being more standard in mainstream languages, encourages breaking pieces of functionality apart while keeping the namespace easy to navigate it's not that great man. the namespace thing is a non issue in any lang that has an actual package/module system anyway? i really don't see nested function defs as some killer feature
|
# ? Jun 9, 2016 17:09 |
fritz posted:now imagine it in the hands of academics Python has caught on in astronomy, even among the older people. Mostly they just don't use nested functions.
|
|
# ? Jun 9, 2016 17:20 |
|
VikingofRock posted:So I've never really run into a use case for fully heterogenous lists. When do people use them? I'm assuming there must be some use case since so many weaker-typed languages tote them as features. I tried to think if an good example but none qualified as a "good" use case. I suppose you could pattern match against the type to determine behaviour? Otherwise you're just using an implicit interface e: and even then you've really just got a homogeneous list of "object"
|
# ? Jun 9, 2016 17:23 |
leftist heap posted:it's not that great man. the namespace thing is a non issue in any lang that has an actual package/module system anyway? i really don't see nested function defs as some killer feature Nested functions are often equivalent to closures, which are super useful. I'm writing some fairly generic code in C right now, and it sucks having to pass around (foo)(*function)(bar, void *) for a pointer to a function which takes a bar and maybe some other stuff as input and returns a foo (admittedly maybe there's a better way to do that though).
|
|
# ? Jun 9, 2016 17:35 |
|
java basically had heterogenous lists before 1.5 and it sucked really hard. imagine a boot casting an object to an interface forever
|
# ? Jun 9, 2016 17:42 |
|
maybe i'm prejudiced against nested functions because python weenies in particular seem to have hardons for it. or maybe i've just been in java world too long
|
# ? Jun 9, 2016 17:46 |
leftist heap posted:imagine a boot casting an object to an interface forever
|
|
# ? Jun 9, 2016 17:57 |
|
VikingofRock posted:Nested functions are often equivalent to closures, which are super useful. I'm writing some fairly generic code in C right now, and it sucks having to pass around (foo)(*function)(bar, void *) for a pointer to a function which takes a bar and maybe some other stuff as input and returns a foo (admittedly maybe there's a better way to do that though). something like this?? code:
|
# ? Jun 9, 2016 18:01 |
|
VikingofRock posted:So I've never really run into a use case for fully heterogenous lists. When do people use them? I'm assuming there must be some use case since so many weaker-typed languages tote them as features. scheme programmers like to use heterogeneous lists as an ad-hoc record type. i consider this an argument against them. i've basically never wanted heterogeneous lists in a language that doesn't have them. i guess i might have used a std::vector<boost::any> once? i don't think it survived to the final version of the code though
|
# ? Jun 9, 2016 18:17 |
Oh yeah it wasn't the verbosity I was complaining about. It's just an awkward thing to work with compared to a closure.
|
|
# ? Jun 9, 2016 18:18 |
|
VikingofRock posted:So I've never really run into a use case for fully heterogenous lists. When do people use them? I'm assuming there must be some use case since so many weaker-typed languages tote them as features. Options/configs for something. Imagine that instead of going with binary flags you can pass in [read, write, {encoding, "utf-8"}, {buffer, Size::Int, Delay::Int}] as a list of config options. Makes for readable stuff. It's nice because you can use similar stuff for TCP sockets like [raw, keep_alive, whatever] and merge that list with SSL options like [{private_key, "some data"}, {cipher_suites, ["AES-...", "ECDHA-..."]}, {sni_hostname, "example.org"}, ...] and have it work together. I guess you would enumerate all the possible combinations in your type signature if you really wanted to, you're just not forced to do it in a dynamic lang.
|
# ? Jun 9, 2016 18:19 |
|
MononcQc posted:Options/configs for something. Imagine that instead of going with binary flags you can pass in [read, write, {encoding, "utf-8"}, {buffer, Size::Int, Delay::Int}] as a list of config options. Makes for readable stuff. a list of key-value pairs is just a lovely dictionary. i think there's plenty of obvious use-cases for a dictionary with heterogeneous values.
|
# ? Jun 9, 2016 18:37 |
|
Plorkyeran posted:a dictionary with heterogeneous values you mean like an object?
|
# ? Jun 9, 2016 18:43 |
|
Heterogeneous anything usually only makes sense if you pretend algebraic datatypes don't exist.MononcQc posted:It's nice because you can use similar stuff for TCP sockets like [raw, keep_alive, whatever] and merge that list with SSL options like [{private_key, "some data"}, {cipher_suites, ["AES-...", "ECDHA-..."]}, {sni_hostname, "example.org"}, ...] and have it work together. I guess you would enumerate all the possible combinations in your type signature if you really wanted to, you're just not forced to do it in a dynamic lang.
|
# ? Jun 9, 2016 18:45 |
|
leftist heap posted:imagine a boot casting an object to an interface forever thread title please
|
# ? Jun 9, 2016 18:48 |
|
Plorkyeran posted:a list of key-value pairs is just a lovely dictionary. i think there's plenty of obvious use-cases for a dictionary with heterogeneous values. You have single values, some pairs, some that are triple, and some that are nested structures. You can fit them into a key-value structure if you really must, but that's because you'd have no better way of expressing things. A hash map also has no concept of ordering in cases where that might be important.
|
# ? Jun 9, 2016 18:50 |
|
Ralith posted:Heterogeneous anything usually only makes sense if you pretend algebraic datatypes don't exist. Yeah I don't know. Whenever I use these I also add type annotations for Dialyzer to catch up. The types are just not necessary to make it work, and not all type systems are necessarily nifty enough to allow that without problem, or to encode all constraints properly (i.e. you probably can't have a file that is both using 'raw' encoding and a 'utf8' encoding at once, but encoding that in the type system is often not doable and still requires external logic anyway)
|
# ? Jun 9, 2016 18:51 |
|
MononcQc posted:The types are just not necessary to make it work, and not all type systems are necessarily nifty enough to allow that without problem, or to encode all constraints properly (i.e. you probably can't have a file that is both using 'raw' encoding and a 'utf8' encoding at once, but encoding that in the type system is often not doable and still requires external logic anyway)
|
# ? Jun 9, 2016 18:57 |
|
Ralith posted:If your type system is that much less expressive than C's I don't think it gets to be called a type system anymore. tell me more about that type system of yours that can support multiple disjoint options together but forbid specific combinations of them exclusively. E: example, I can configure an SSL client to use either the option '{private_key, Blob}', or '{private_key_file, Path}', and if either is used, so must be the option '{private_key_pass, Password}', but you also cannot both have 'private_key' and 'private_key_file' options specified at once. How do you express that in C's type system in a non-cumbersome way to use? MononcQc fucked around with this message at 19:07 on Jun 9, 2016 |
# ? Jun 9, 2016 19:02 |
|
VikingofRock posted:So I've never really run into a use case for fully heterogenous lists. When do people use them? I'm assuming there must be some use case since so many weaker-typed languages tote them as features. they're nice for things like (elt "foo" 0)
|
# ? Jun 9, 2016 19:46 |
|
VikingofRock posted:Oh yeah it wasn't the verbosity I was complaining about. It's just an awkward thing to work with compared to a closure. the one killer feature i wish for in c are type-checked typedefs instead of just aliases. that's how everyone wants to use them anyway. Dr Monkeysee fucked around with this message at 20:17 on Jun 9, 2016 |
# ? Jun 9, 2016 20:14 |
|
MononcQc posted:tell me more about that type system of yours that can support multiple disjoint options together but forbid specific combinations of them exclusively. code:
Ralith fucked around with this message at 20:22 on Jun 9, 2016 |
# ? Jun 9, 2016 20:19 |
Dr Monkeysee posted:the one killer feature i wish for in c are type-checked typedefs instead of just aliases. that's how everyone wants to use them anyway. What do you mean by this?
|
|
# ? Jun 9, 2016 20:22 |
|
VikingofRock posted:What do you mean by this? code:
|
# ? Jun 9, 2016 20:35 |
|
Ralith posted:That's different than your original example, but: That solution doesn't keep me from submitting the two variations of that struct in a single linked list for example, which is kind of important when we're talking of mixed types containers. The enforcement of that is still left to the runtime.
|
# ? Jun 9, 2016 20:39 |
|
a fully heterogeneous list is completely useless if the position of the elements is fixed and you determine their types that way, you have a tuple, not a list otherwise, you must have some tag on each item that you check to tell what it is, so use an algebraic datatype like Ralith said, and now it's a homogeneous list "but i don't want to write a type that enumerates all my cases" is not really an argument when type inference is a thing
|
# ? Jun 9, 2016 20:40 |
|
MononcQc posted:That solution doesn't keep me from submitting the two variations of that struct in a single linked list for example, which is kind of important when we're talking of mixed types containers. The enforcement of that is still left to the runtime. The point is heterogeneously typed containers are pretty much always the wrong solution. JewKiller 3000 posted:"but i don't want to write a type that enumerates all my cases" is not really an argument when type inference is a thing Ralith fucked around with this message at 20:56 on Jun 9, 2016 |
# ? Jun 9, 2016 20:54 |
|
MononcQc posted:That solution doesn't keep me from submitting the two variations of that struct in a single linked list for example, which is kind of important when we're talking of mixed types containers. The enforcement of that is still left to the runtime. which is why you use an options struct which only has a single struct key field rather than a stupid linked list that lets you express all sorts of nonsense
|
# ? Jun 9, 2016 20:55 |
|
MononcQc posted:tell me more about that type system of yours that can support multiple disjoint options together but forbid specific combinations of them exclusively. Really sounds like an argument for OOP rather than untyped lists with surprise additional requirements. Even a dictionary with nullable entries would be better.
|
# ? Jun 9, 2016 20:57 |
|
pointsofdata posted:Really sounds like an argument for OOP rather than untyped lists with surprise additional requirements. Even a dictionary with nullable entries would be better.
|
# ? Jun 9, 2016 21:00 |
|
Y'all my point is not that it is impossible to do it any other way, but that this flexible format is way harder to replicate through a type system but absolutely dead simple to represent in any loving dynamic language out there. To properly replicate the kind of semantics you can have with such an option list you tend to usually defer a part or all of its enforcement to user-written code and the runtime and it cannot be fully represented into the type system unless you're able to do fancy rear end constraints you would see in probably Haskell compiler extensions, agda, or some other similar language. I'm not saying there's no equivalence, nor that there is no gain in getting the compiler to do part of the work; there's plenty. But you've all spent half a dozen post with various recommendations somewhat reminding me of the "how do you do a list in XML" debate while dynamic language people have just written their loving list and moved on a page ago. The countdown is set until the discussion devolves into the bob harper argument about all dynamic languages being in fact unityped and a rehash of the same idiotic debate that has been had 500 times on who has the cleverest way to frame their viewpoint to prove that what they will keep doing anyway is right.
|
# ? Jun 9, 2016 21:04 |
|
Ralith posted:He wants easily but not elegantly. wrapping all your types in a struct is awkward and obscures your intent. like, size_t has deliberate semantics beyond "an unsigned integer of a certain size" and it's annoying that if i write a function that takes a size_t it'll also blindly accept a uint64_t or a long long or whatever (even aside from the fact that it'll accept *different* types on a different architecture). if i say i take a size_t then i should *only* accept a size_t. and if you need to punch through the type system that's what casts are for. Dr Monkeysee fucked around with this message at 21:08 on Jun 9, 2016 |
# ? Jun 9, 2016 21:06 |
|
i suppose this goes back to what someone said earlier that c is almost entirely about describing the mechanics of what the computer is doing instead of the meaning of what the programmer intent is but strongly-typed typedefs seems like not much to ask.
|
# ? Jun 9, 2016 21:08 |
|
MononcQc posted:Y'all my point is not that it is impossible to do it any other way, but that this flexible format is way harder to replicate through a type system but absolutely dead simple to represent in any loving dynamic language out there. but you've done the exact opposite? you've taken something that's trivial even with a lovely type system like C's and shown that you can do it in a much more error prone and not any simpler way in a dynamic language if we don't have record types then we need heterogeneous lists so that we can fake them is not a very compelling argument that heterogeneous lists are a good thing
|
# ? Jun 9, 2016 21:11 |
|
i still dont even understand the use case presented
|
# ? Jun 9, 2016 21:16 |
|
|
# ? Jun 12, 2024 08:15 |
|
Plorkyeran posted:but you've done the exact opposite? you've taken something that's trivial even with a lovely type system like C's and shown that you can do it in a much more error prone and not any simpler way in a dynamic language Record types can coexist there. The idea is just that for some configs (which was a random example), it's much simpler to go [a, b, {c, value}, {d, something, other}] and then doing a runtime check on the values format that declare 4 types of records and then the list union and then still need to go over it at runtime to ensure the conditions are respected (i.e. you can't set b and c at the same time, but individually they're fine). In both cases, you'll end up with manual validation and hopefully a test to confirm it and what your type system has saved you is from a typo going 'oh shoot I entered p instead of b!'
|
# ? Jun 9, 2016 21:17 |