lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Note that I don't like also the existing curryfied syntax of Lua (based only on ambiguous space separators). A "chaining" syntax using an explicit operator is possible and would be preferable without any syntaxic ambiguity.
The alternate would be to have custom syntax parsers in Lua, using an alternate syntax with some prefix. The alternate parser could be shipped or should be pluggable, e.g. with specific string prefixes, which would still be declarable and implementable in pure Lua with a commission interface for custom "loaders". Such thing could be handy for adding custom loaders for Perl-style regexps (internally compiled into Lua patterns by the loader), or parsers for common data formats (e.g. JSON, XML, RDF and binary variants, compressors...) like they also exist in PostScript.

Le mar. 22 oct. 2019 à 12:59, <> a écrit :
hi there! :)

my suggestion:

dont make a general curry function or anything like that, it would
make all of ur codes only heavier with a thin layer that applies to a
lot of things and that will be called very often... not much, and
sometimes it is necessary, but think speedwise always to not let
urself step onto that path if it can be avoided, cuz they will grow
deep roots into ur projects...

so instead make factories (only) when they are needed, and u can give
it 2 "levels" (the 2 calls) for the most of the purposes, where the
1st level will generate out the specialized target function, cuz the
new one will be used (2nd level) more often and u can save this
generated one, so u just saved a lotsa operations for all the rest of
the uses via memoizing this new prototype function; but with the 1st
level, u can still have any kinda flexibility to write some arguments
instead of new codes! :) (then u will most likely need a naming
convention to generate out some of the variants u wanted :D i know
that... multiple parameters of the 1st level will most likely make it
necessary...) actually i can imagine something with more than 2 levels
but generally this can be fine...

btw even this will be needed too rarely to make too fancy general
stuffs for it, but anyhow never be afraid of making such nasty ideas
real, one day u will be happy even if it will be just the base for
something better... :D except if u really want to make any paradigm
shift for any idea, when u will need probably these kinda language

i would also like to suggest to always use the most primitive variant
of the things, so like functions instead of methods, iterators instead
of coroutines, tables instead of trying to hack the varargs or crying
after tuples, arrays, dictionaries, proxy tables and whatever like (no
offense for any1 around! :D ) and one day u will really need these
things that i just told u to avoid, but wait for that day when it will
really come, and the final results will be much more pure and simple,
while u will have a lotsa time to make the best mental model for
everything before u would wire alltogether everything for delayed pain

actually this is just a suggestion, but i know that i really doesnt
belong under the flagship of any specific paradigm, so a lotsa various
paradigms gave me funds for mine and maybe this wont be beneficial if
it is forced, but still, these rules of thumb serve me really nicely,
and i think mostly fixed programming paradigms can also be more or
less paired with these without making mess and any inconvenience by
breaking paradigm rules...

(sorry if i wasnt the clearest in my words, i has 3 days of
partyharding behind my shoulders that i still feel in my bones...)

bests, and have fun! :D