lua-users home
lua-l archive

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



On 2019-10-22 3:50 p.m., Philippe Verdy wrote:
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.
In EXP context, but not EXPLIST context, I see no particular reason why we couldn't do it with variables: 

local foo = a b () -- equivalent to "local foo = a; b()"
local foo = (a b ()) -- equivalent to "local foo = a(b)()"
This makes it lisp-like but basically is just a (trivial IMO) bit of sugar. Basically just tell expr/subexpr/simpleexp/suffixedexp whether they are in a explist (see lparser.c), and accept names in suffixedexp if so. Note that you'd still need () in a funcargs - foo(a b ()) would be illegal syntax and you'd have to use foo((a b ())) instead. anyway, just an idea.
Le mar. 22 oct. 2019 à 12:59, szbnwer@gmail.com <mailto:szbnwer@gmail.com> <szbnwer@gmail.com <mailto:szbnwer@gmail.com>> 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
    hacks...

    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
    :D

    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