Dependencies: Are "optional requirements" possible at all?

[Pi-C]

I do this often in my mods. You have to write code to handle it. Make any mods that may or may not appear optional using ?,

I'm afraid you didn't understand the question correctly -- I admit it's phrased in a way that makes it easy to get it wrong.

I was familiar with the basic dependency operators: hard dependency (must be active), optional dependency ("? mod_name" -- mod may or may not be activated), and conflict ("! mod_name" -- having conflicting mods installed together with your own will break stuff). I've also learned about hidden optional dependencies ("(?) mod_name") that are not shown in the mod manager, but provide that mod_name is loaded before your own mod. However, I didn't look for "optional dependencies", but "optional requirements" (a term I used for lack of a better one). What I meant was a hard dependency on one mod from a list of mods or, more generally, using logic operators between dependencies. Could be as easy as "require A and (B or C)", or more complex like "require A and ( (B and not C) or (D and E))". Something like that isn't supported by the game yet, unfortunately.

Here is a piece of code I have for a chemistry mod. It optionally requires a number of mods that I know add chemistry recipes to the game. It doesn't even ask about particular mods, although you could do that with the api, ask for them by name, instead, this code just trolls the recipes, whatever is available from any mod, and copies the recipes into new recipes that work with my chemistry buildings to make the same things.

Code: Select all

require("util")

function add_recipe_to_tech(tech_name,recipe_name)
	if data.raw["technology"][tech_name] then
		table.insert(data.raw["technology"][tech_name].effects, {
			type="unlock-recipe",
			recipe=recipe_name
		})
	end
end

Interesting, I also use table.insert, and it works although I don't have require("util"). I'd assumed that was more or less a standard class that would always be there. Also, I haven't found any documentation in the modding wiki on these things.

Code: Select all

if ingredient.type ~= "fluid" then
	solid_input_count = solid_input_count + 1
end

That seemed so wrong! Then I realized that "~=" means "is not equal" instead of "matches string".

[Qon]

Normalize recipes into a non-ambigious form obviously. If you think that's only a few lines of code you haven't really looked at all the stuff that recipes can contain.

That sounds like 10 times too many lines though. I looked at the Recipe documentation. There's several things to Qonsider but nothing that requires hundreds of lines of code.

Library code. 7 lines, but not specific to normalization or recipes. A real language would come with these included:

Code: Select all

function has_value(tab, val) for _, v in ipairs(tab) do if v == val then return true end end end
function B(f, g) return function(a) return f(g(a)) end end --[[Bluebird ( . )--]]
function map(a, f)
    local r = {}
    for i, c in ipairs(a) do table.insert(r, f(c, i, a)) end
    return r
end

27 lines for the recipe normalization:

Code: Select all

function typeFromName(name) return (data.raw.fluid[name] and 'fluid' or 'item') end
function norm(keys) return function(item)
    local n = {}
    for k, v in pairs(keys) do if string.find(k, '^%d+$') then n[v] = item[v] or item[k] elseif not n[k] then n[k] = v end end
    for k, v in pairs(item) do if not string.find(k, '^%d+$') then n[k] = v end end
    return n
end end
function rdata(recipe)
    if not recipe then return nil end
    local r = {}
    local b = B(norm{'name', 'count', count = 1}, function(item) item.type = typeFromName(item.name) return item end)
    r.results = map(recipe.results or ({{recipe.result, recipe.result_count}}), b)
    r.ingredients = map(recipe.ingredients, b)
    return r
end
local general_data = {'category', 'subgroup', 'crafting_machine_tint', 'type', 'name', 'order', 'localised_name', 'localised_description',}
function normalize_recipe(recipe)
    local r = {}
    recipe = table.deepcopy(recipe)
    r.normal = rdata(recipe.normal)
    r.expensive = rdata(recipe.expensive) or table.deepcopy(r.normal)
    for k, v in pairs(recipe) do if has_value(general_data, k) then r[k] = v end end
    if not r.normal and not r.expensive then r.expensive = rdata(recipe) end
    r.normal = r.normal or table.deepcopy(r.expensive)
    r.icons = (recipe.icon or recipe.icons) and map(recipe.icons or {{recipe.icon, recipe.icon_size}}, norm{'icon', 'icon_size', icon_size = 32}) or nil
    return r
end

I've only done some minor testing so might Qontain some bug. Just threw it together to be able to CLoC it. Some places might benefit from extra newlines to make it readable since Lua has ugly bloated syntax. But I didn't choose Lua so I'm not going to take responsibility for the mistakes of others. I could make it longer but I don't think I could make it hundreds of lines even if I tried
Maybe I misunderstood what you meant by normalization?

[eradicator]

Personal discussion with Qon

Your coding style is pretty difficult to read with all those unnamed variables. If you add proper indentation and named variables to that you are already at 100+ lines. If you make it readable for "normal people" probably more. Also pretty sure you're treating normal/expensive=false wrongly.

My personal "several hundret lines" normalizer is a) written very verbose and b) has to flip some of the vanilla default values for some attributes as i consider them wrong (like making enabled default to false instead of true). And fixes some issues like difficulty dependancy of flags where it makes no sense (i.e. "hide_from_stats" etc makes no sense to be different for normal/expensive).

Edit: Added spoiler to personal discussion to improve future thread readability.

[Qon]

Your coding style is pretty difficult to read with all those unnamed variables. If you add proper indentation and named variables to that you are already at 100+ lines.

"proper indendation and line breaks" still don't get it above 50 lines. Longer variable names don't increase line count. And the 1 char variables are loop variables or just temp storage for the return value, so it's standard to not give them pointless names.

If you make it readable for "normal people" probably more.

Any professional programmer will understand the simple functional style. Without a formal introduction, it is probably not known to many amateurs. But code understandability and maintainability are judged by professionals. Doesn't make sense to make it understandable to those that don't want to learn more advanced Qoncepts. It might be possible to make almost anything with just if and for but it would be silly to do so. Some topics are irreducibly complex and need higher abstraction to be manageable. But Bluebird and Map are defined for those that are unfamiliar and they are just a handful of simple lines so for those that want to learn how they work, just read them

Also pretty sure you're treating normal/expensive=false wrongly.

Yeah, oops. Well, it wouldn't make the code that much longer to handle that.

[Adamo]

I did understand. I'm making the case to you that it is equivalent to simply require them both as optional dependencies and then write the code to determine which ones popped and prioritize the data as you see fit.

I do this often in my mods. You have to write code to handle it. Make any mods that may or may not appear optional using ?,

I'm afraid you didn't understand the question correctly -- I admit it's phrased in a way that makes it easy to get it wrong.

I was familiar with the basic dependency operators: hard dependency (must be active), optional dependency ("? mod_name" -- mod may or may not be activated), and conflict ("! mod_name" -- having conflicting mods installed together with your own will break stuff). I've also learned about hidden optional dependencies ("(?) mod_name") that are not shown in the mod manager, but provide that mod_name is loaded before your own mod. However, I didn't look for "optional dependencies", but "optional requirements" (a term I used for lack of a better one). What I meant was a hard dependency on one mod from a list of mods or, more generally, using logic operators between dependencies. Could be as easy as "require A and (B or C)", or more complex like "require A and ( (B and not C) or (D and E))". Something like that isn't supported by the game yet, unfortunately.

Here is a piece of code I have for a chemistry mod. It optionally requires a number of mods that I know add chemistry recipes to the game. It doesn't even ask about particular mods, although you could do that with the api, ask for them by name, instead, this code just trolls the recipes, whatever is available from any mod, and copies the recipes into new recipes that work with my chemistry buildings to make the same things.

Code: Select all

require("util")

function add_recipe_to_tech(tech_name,recipe_name)
	if data.raw["technology"][tech_name] then
		table.insert(data.raw["technology"][tech_name].effects, {
			type="unlock-recipe",
			recipe=recipe_name
		})
	end
end

Interesting, I also use table.insert, and it works although I don't have require("util"). I'd assumed that was more or less a standard class that would always be there. Also, I haven't found any documentation in the modding wiki on these things.

Code: Select all

if ingredient.type ~= "fluid" then
	solid_input_count = solid_input_count + 1
end

That seemed so wrong! Then I realized that "~=" means "is not equal" instead of "matches string".

[eradicator]

Personal discussion with Qon

Your coding style is pretty difficult to read with all those unnamed variables. If you add proper indentation and named variables to that you are already at 100+ lines.

"proper indendation and line breaks" still don't get it above 50 lines. Longer variable names don't increase line count. And the 1 char variables are loop variables or just temp storage for the return value, so it's standard to not give them pointless names.

If you make it readable for "normal people" probably more.

Any professional programmer will understand the simple functional style. Without a formal introduction, it is probably not known to many amateurs. But code understandability and maintainability are judged by professionals. Doesn't make sense to make it understandable to those that don't want to learn more advanced Qoncepts. It might be possible to make almost anything with just if and for but it would be silly to do so. Some topics are irreducibly complex and need higher abstraction to be manageable. But Bluebird and Map are defined for those that are unfamiliar and they are just a handful of simple lines so for those that want to learn how they work, just read them :)

Also pretty sure you're treating normal/expensive=false wrongly.

Yeah, oops. Well, it wouldn't make the code that much longer to handle that.

I am at this point unsure why you even bothered to write that "answer".

Edit: Added spoiler to personal discussion to improve future thread readability.

[Qon]

You said normalization was hundreds of lines. It was off by an order of magnitude of how I would solve it so I was confused if normalization was all that was going on in those lines. Turns out you did some other things also, like changing defaults and restructuring to your own format. But you said my answer was confusing and 100+ lines with "proper indentation". Which I disagreed with. And if there's something that's confusing about the code I can explain it if you want, just tell me which part

I am at this point unsure why you even bothered to write that "answer".

I'm responding to what you wrote, why is it an "answer" instead of an answer? Why bother writing anything at all? Isn't that why we are on a forum, to write and read? If you don't want to do that then... don't?

[eradicator]

Personal discussion with Qon

You said normalization was hundreds of lines. It was off by an order of magnitude of how I would solve it so I was confused if normalization was all that was going on in those lines. Turns out you did some other things also, like changing defaults and restructuring to your own format. But you said my answer was confusing and 100+ lines with "proper indentation". Which I disagreed with. And if there's something that's confusing about the code I can explain it if you want, just tell me which part :)

I am at this point unsure why you even bothered to write that "answer".

I'm responding to what you wrote, why is it an "answer" instead of an answer? Why bother writing anything at all? Isn't that why we are on a forum, to write and read? If you don't want to do that then... don't? ;)

Well, ya know. Maybe it's just me. But when you say something like this

Any professional programmer will understand the simple functional style. Without a formal introduction, it is probably not known to many amateurs. But code understandability and maintainability are judged by professionals.

Do you not percieve yourself as extremely patronizing and arrogant? To me it looks mostly like you wanted to brag about your own "professionalism". Especially since you're saying it on a forum full of amateur and hobby-coders. (And i say "coders" here on purpose). Your tendency to ignore basic english spelling strengthens that impression to me. Written communication is difficult i know. And i'm half expexting a "it's your fault for not being a native speaker"-type answer. But maybe it's worth some time to think about it.

Edit: Added spoiler to personal discussion to improve future thread readability.

If you're actually interested in creating a high-quality standard recipe normalizer...

After proper indentation and naming of all the variables i'm at 85 lines for your code (Based on the common community style guide i percieve exists by having looked at a great many other mods, plus my preference for python-style in-block endings which do not affect line count. I also cut out "typeFromName" because it's used only once). And given the fact that my "200+ lines estimate" was meant as an eyeball estimate for intermediate hobby programmers this is hardly "off by an order of magnitude".

Code: Select all

function promise(f2,f1)
  return function(arg)
    return f2( f1(arg) )
    end
  end

function map (tableA,f)
  local new = {}
  for index, value in ipairs(tableA) do
    table.insert(new, f(value, index, tableA))
    end
  return new
  end
  
function reformat (item) --no good name for this
  local new = {}
  for k,v in pairs(item_defaults)       do
    if string.find(k, '^%d+$') then --if type(k) == 'number' then
      new[v] = item[v] or item[k]
    elseif (not new[k]) then
      new[k] = v
      end
    end
  for k, v in pairs(item) do
    if not string.find(k, '^%d+$') then
      new[k] = v
      end
    end
  return new
  end

function add_type(item)
  item.type = data.raw.fluid[item.name] and 'fluid' or 'item'
  return item
  end
  
local non_difficulty_data = {
  'name'                  = true,
  'type'                  = true,
  'order'                 = true,
  'localised_name'        = true,
  'localised_description' = true,
  'crafting_machine_tint' = true,
  'category'              = true,
  'subgroup'              = true,
  }
  
function difficulty_data(difficulty)
  if (difficulty == nil) then return end
  local new = {}
  local normalize_and_type = promise(reformat({'name', 'count', count = 1}), add_type)
  new.results = map(
    difficulty.results or {{difficulty.result, difficulty.result_count}},
    normalize_and_type
    )
  new.ingredients = map(
    recipe.ingredients,
    normalize_and_type
    )
  return new
  end

local deepcopy = util.table.deepcopy
function normalize_recipe(old_recipe)
  local new     = {}
  old_recipe    = deepcopy(old_recipe)
  new.normal    = difficulty_data(recipe.normal   )
  new.expensive = difficulty_data(recipe.expensive) or deepcopy(new.normal)
  for k,v in pairs(old_recipe) do
    if non_difficulty_data[k] then
      new[k] = v
      end
    end
  if not (new.normal or new.expensive) then
    new.expensive = difficulty_data(old_recipe)
    end
  new.normal    = new.normal or deepcopy(new.expensive)
  new.icons     = not (recipe.icon or recipe.icons) and nil or map(
    recipe.icons or {{recipe.icon, recipe.icon_size}},
    reformat{'icon', 'icon_size', icon_size = 32}
    )
  if old_recipe.normal    == false then new.normal   .enabled = false end
  if old_recipe.expensive == false then new.expensive.enabled = false end
  return new
  end

But sure here's some questions:

What is "bluebird"? Google finds exactly one hit, which seems to be a JS library. And it seems to be what you really meant was the general concept of a "promise"?

Why...are you using string.find instead of type()?

And some problems:

typeFromName looks like it's being called onto the item table before ".name" is guaranteed to exist. I.e. the "bluebird" function creation has the wrong order of arguments (i fixed this by changing the constructor to take arguments in execution order instead of reverse order).

rdata() completely ignores anything but results and ingredients. Needs another round of norm()'ing for all possible attributes.

typeFromName needs to do something about the case where there's both an item *and* a fluid of that name.

[Qon]

Any professional programmer will understand the simple functional style. Without a formal introduction, it is probably not known to many amateurs. But code understandability and maintainability are judged by professionals.

Do you not percieve yourself as extremely patronizing and arrogant? To me it looks mostly like you wanted to brag about your own "professionalism". Especially since you're saying it on a forum full of amateur and hobby-coders. (And i say "coders" here on purpose). Your tendency to ignore basic english spelling strengthens that impression to me. Written communication is difficult i know. And i'm half expexting a "it's your fault for not being a native speaker"-type answer. But maybe it's worth some time to think about it.

No. And not my intention. Factorio has many hobby coders but also many professionals in various fields, including programming. It's not really an achievement to brag about. It's not even a very specific accomplishment, it's just a statement of vocation. We all (adults) have our fields of expertise, programming is just a relevant field. You wouldn't say that I'm bragging if I state that I'm an adult, even if there are kids on this forum, right?
And I wasn't sure what was hard to understand about the code so I had to assume that it was in part the more esoteric concepts and not just the linebreaks.

I'm just spelling things with "Qon" for my own amusement. Nothing to take notice of.

I'm not a native English speaker either, so nuance might get lost when a message is translated twice and also in text.

And given the fact that my "200+ lines estimate" was meant as an eyeball estimate for intermediate hobby programmers this is hardly "off by an order of magnitude".

Yes, in hindsight I realise that your estimate was for hobby programmers. And the line count doubles when a few more needed line breaks are added.

What is "bluebird"? Google finds exactly one hit, which seems to be a JS library. And it seems to be what you really meant was the general concept of a "promise"?

Bluebird was a comment for myself mostly. It's just a lambda calculus combinator, a language which uses lambda ("anonymous") functions only.
It's the compositional combinator (function composition), written as "." in Haskell. It composes two functions into a new combined function. So not an asynchronous function call wrapper "promise". Though you can compose with those too.

You mentioned your python style preference. I like to use functional programming where it fits. And in languages with proper lambda function syntax it is standard to not split lines between each parameter in you function definition.

Code: Select all

local B = function(f) return function(g) return function(a) return f(g(a)) end end end

Is styled like these:
JS:

Code: Select all

let B = f=>g=>a=> f(g(a))

Haskell:

Code: Select all

B f g a = f (g a)
B = ( . ) -- or just use the built in function

Even though it doesn't make as much sense in Lua as in those languages because of it's awkward syntax. But as I said, I didn't choose Lua and I prefer to make it clear that the functions are going to be curried.

Why...are you using string.find instead of type()?

I didn't feel like checking how Lua stores table arrays. And I thought I had read that Lua table keys were strings (always) like in JS. Because if so the keys would always be strings. But apparently you can do :

Code: Select all

local a = {}
a[1] = 'x'
a['1'] = 'y'
game.print(serpent.block(a))

But you can't do

Code: Select all

game.table_to_json(a) 

with that table. Now I know. So yeah type() would work fine.

And some problems:

typeFromName looks like it's being called onto the item table before ".name" is guaranteed to exist. I.e. the "bluebird" function creation has the wrong order of arguments (i fixed this by changing the constructor to take arguments in execution order instead of reverse order).

Oops.

Code: Select all

function promise(f2,f1)
  return function(arg)
    return f2( f1(arg) )
    end
  end

No. You didn't.
And in function composition, the "reverse" order is the correct order. Mathematicians often read from right to left q:
I switched it in

Code: Select all

function reformat (item) --no good name for this
  local new = {}
  for k,v in pairs(item_defaults)       do

Why rename it if you don't have a good name for it? Reformat is equally good/bad name though I guess. And item_defaults doesn't exist because you removed the second parameter.
I fixed some other bugs you introduced (mostly missed variable renaming) and fixed some bugs I crafted myself earlier. And then styled it to a compromise between the bit excessively compact style (no more for-if combos as single lines) and your style. I don't like python blocks...

Would be 61 non-empty lines if non_difficulty_data was a one-liner.

Code: Select all

function compose(f, g) return function(arg)
    return f(g(arg))
end end

function map(array, f)
    local new = {}
    for i, v in ipairs(array) do
        table.insert(new, f(v, i, array))
    end
    return new
end

function reformat(new_format) return function(item)
    local new = {}
    for k,v in pairs(new_format) do
        if type(k) == 'number' then new[v] = item[v] or item[k]
        elseif (not new[k])    then new[k] = v end
    end
    for k, v in pairs(item) do
        if type(k) ~= 'number' then new[k] = v end
    end
    return new
end end

function add_type(item)
    item.type = data.raw.fluid[item.name] and 'fluid' or 'item'
    return item
end

local non_difficulty_data = {
    name                  = true,
    type                  = true,
    order                 = true,
    localised_name        = true,
    localised_description = true,
    crafting_machine_tint = true,
    category              = true,
    subgroup              = true,
}

function difficulty_data(difficulty)
    if (difficulty == nil) then return end
    local new = {}
    local normalize_and_type = compose(add_type, reformat{'name', 'amount', amount = 1})
    new.results = map(
        difficulty.results or {{difficulty.result, difficulty.result_count}},
        normalize_and_type
    )
    new.ingredients = map(
        difficulty.ingredients,
        normalize_and_type
    )
    return new
end

local deepcopy = util.table.deepcopy
function normalize_recipe(old_recipe)
    local new     = {}
    old_recipe    = deepcopy(old_recipe)
    new.normal    = difficulty_data(old_recipe.normal   )
    new.expensive = difficulty_data(old_recipe.expensive) or deepcopy(new.normal)
    for k,v in pairs(old_recipe) do
        if non_difficulty_data[k] then new[k] = v end
    end
    if not (new.normal or new.expensive) then
        new.expensive = difficulty_data(old_recipe)
    end
    new.normal    = new.normal or deepcopy(new.expensive)
    new.icons     = not (old_recipe.icon or old_recipe.icons) and nil or map(
        old_recipe.icons or {{old_recipe.icon, old_recipe.icon_size}},
        reformat{'icon', 'icon_size', icon_size = 32}
    )
    if old_recipe.normal    == false then new.normal   .enabled = false end
    if old_recipe.expensive == false then new.expensive.enabled = false end
    return new
end

[eradicator]

For better thread readability for future readers i'll put the non-coding bits of the discussion into a spoiler.

Personal discussion with Qon

Well. If it's unintentional i'm fine with it. But i do think (not limited to this thread) that your utterings lack tactfulness from time to time.

But code understandability and maintainability are judged by professionals.

This imho is a typical "only cooks are allowed to judge the taste of meals" statement. In a factorio context the maintain/usability will be judged soley by the user of a bit of code (i.e. some random modder).

And I wasn't sure what was hard to understand about the code so I had to assume that it was in part the more esoteric concepts and not just the linebreaks.

Mostly the (to me) weird naming conventions. My brain works far better with explicit names (or names that fit conventions that *i* know). After i had "fixed" that part it wasn't that difficult. And now i know what a curried / partially applied function is (doing this as a hobby i don't usually need to know the official name for the concepts i use). Also i did get some confusion out of your mapping function taking a function with three arguments when you only ever use one (which i assume is because that's how it works in one of the languages you like more).

Now that you said you prefer Haskell may i assume you do a lot of mathematic programming? To me that would fit with the pattern that you think f,g,h style function names (a mathematic naming convention) is more common/correct/professional than i percieve it. (My preference being f1, f2, f3 as you have seen.)

I'm just spelling things with "Qon" for my own amusement. Nothing to take notice of.

Can't really "not take notice" of something that jumps into my face *every* time i read any of your posts. I.e. to me it's a joke repeated too often, maybe you can relate to that.

I don't like python blocks...

And i don't like 4-space indentation :D. I only mentiod python to explain why my block endings were indented differently.

No. You didn't. :)
And in function composition, the "reverse" order is the correct order. Mathematicians often read from right to left q:

Doh. Switched them one time too often. It was late..
That's just another convention though. Not everyone is a mathematician, and the input order doesn't affect functionality. Btw i was sure you'd pick on that when i changed it :e.

Why rename it if you don't have a good name for it?

I tried several names, but none fit well. It was late. So before i gave up i at least added a comment because i didn't remember your name by then.

I fixed some other bugs you introduced (mostly missed variable renaming)

'twas *really* late.

So...as for the code. There's still the issue that difficulty_data() strips off everything except .results and .ingredients. And it also needs to handle the special case "not (normal or expensive)" where you shove the whole recipe into it, but have to prevent stuff like .name, .type, etc from bleeding into the difficulty nodes, which reformat() doesn't do. And main_product defaults to nil so i'm not sure how to handle that within your "style". Also i noticed that you can't default "amount=1" because that would conflict with probability based recipes that use amound_min and amount_max instead.

Code: Select all

function enforce_format(new_format) return function(difficulty)
  local new = deepcopy(new_format)
  for k,v in pairs(difficulty) do
    if new[k] ~= nil then
      new[k] = v
      end
    end
  return new
  end
end

local difficulty_defaults = {
  energy_required            = 0.5   ,
  emissions_multiplier       = 1.0   ,
  requester_paste_multiplier = 30    ,
  overload_multiplier        = 0     ,
  enabled                    = true  ,
  hidden                     = false ,
  hide_from_stats            = false ,
  allow_decomposition        = true  ,
  allow_as_intermediate      = true  ,
  allow_intermediates        = true  ,
  always_show_made_in        = false ,
  show_amount_in_title       = true  ,
  always_show_products       = false ,
  main_product               = nil   , --for completeness
  }

function difficulty_data(difficulty)
    if (difficulty == nil) then return end
    
    local new = enforce_format(difficulty_defaults)(difficulty)
    new.main_product = difficulty.main_product --because enforce_format doesn't handle nil defaults

    local normalize_and_type = compose(add_type, reformat{'name', 'amount'})
    new.results = map(
        difficulty.results or {{difficulty.result, difficulty.result_count}},
        normalize_and_type
    )
    new.ingredients = map(
        difficulty.ingredients,
        normalize_and_type
    )    
    return new
end

[Qon]

For better thread readability for future readers i'll put the non-coding bits of the discussion into a spoiler.

Personal discussion with Eradicator

But code understandability and maintainability are judged by professionals.

This imho is a typical "only cooks are allowed to judge the taste of meals" statement. In a factorio context the maintain/usability will be judged soley by the user of a bit of code (i.e. some random modder).

What I meant to say was something more like a person can say "This is difficult to understand for me" while only a professional(/experienced) programmer is really qualified to say something like "this code is (objectivly) hard to understand and therefore bad and needs to be improved". Some tools of the trade make complex problems manageble. And some of them are of course not known by everyone. Professionals use all of their available tools when they are the right one for the job. They don't only use the hammer because everyone knows that it is used to thwack stuff with so they can follow along and build their own skyscrapers

If you want to modify a code then only thing thing that really matters to you (if you aren't going to share it later) is how understandable it is to you though.

For most code you shouldn't need the knowledge to understand a piece of code to use it, but making it "simpler" by using less advanced abstraction only makes code worse in the long term. It might make an individual segment of the code understandable to everyone but it can completely eliminate any possibility for anyone to understand the whole codebase. You don't make an advanced mathematical textbook only using the 1000 most common words to make it accessible to 5 year olds with a limited vocabulary. It doesn't actually make the subject approachable, just fakes it. But you would get a much longer text that is incomprehensible to a mathematician just because it's so long that you can't really get anywhere before you forgot where you started.

And I agree that there were some omitted but needed newlines and bad variable names in the first version. Hope this makes more sense.

And I wasn't sure what was hard to understand about the code so I had to assume that it was in part the more esoteric concepts and not just the linebreaks.

Mostly the (to me) weird naming conventions. My brain works far better with explicit names (or names that fit conventions that *i* know). After i had "fixed" that part it wasn't that difficult. And now i know what a curried / partially applied function is (doing this as a hobby i don't usually need to know the official name for the concepts i use). Also i did get some confusion out of your mapping function taking a function with three arguments when you only ever use one (which i assume is because that's how it works in one of the languages you like more).

Now that you said you prefer Haskell may i assume you do a lot of mathematic programming? To me that would fit with the pattern that you think f,g,h style function names (a mathematic naming convention) is more common/correct/professional than i percieve it. (My preference being f1, f2, f3 as you have seen.)

Actually, I prefer js. But I was introduced to functional programming through Haskell and js is actually really flexible and it works fine to use the functional style in it, though with a performance hit that is irrelevant in most cases. Haskell is a pragmatic extension/syntax layer to the theoretical foundation that is lambda calculus. The entire functional style is born out of and heavily inspired by mathematics and its notation. So the concepts are mathematical ones. So when a mathematician sees a composed function (f . g) being mapped over a list they understand immediately which function is applied first. It would be extremely confusing if you just follow the mathematical syntax and conventions for almost everything but make sudden exceptions for random cases when you are working in a functional style. If the composition happened in the context of more imperative code then you could make the case that compose should take the function parameters in the order that they are applied. But when using using it in map then you should follow the convention or abandon functional programming completely q:

And that is also why they functions are named f and g. And the argument should also be a 1 letter name really because compose doesn't care what it is. In ln lambda calculus all you have is function definition and application. So a is also a funtion in

Code: Select all

λfga.f(g a)

You can compose composed functions too etc. B(f1, B(f2, f3)) or f1 . f2 . f3
f & g aren't really "more correct", in mathematics <letter subscript number> is common too. But for composition it is just common (the wikipedia article uses those too) to use f & g since you have only 2 of them.

Map is here actually defined as it is in JavaScript and not as it is used in Haskell. The extra parameters are not used here but are neat to have available sometimes. It is a function that I use as a library function common to other mods I have made. It has some code to deal with generators also and not just arrays in my mods though if you peek at those.

And i don't like 4-space indentation . I only mentiod python to explain why my block endings were indented differently.

I usually use 2-space indentation but specifically for Lua and Python that don't have {brace} blocks I double up in the indentation to make it readable. My text editor color codes matching {[(braces)]} so it's easy to see how things relate but Lua designers really like making mistakes just to be different and annoying.

So...as for the code. There's still the issue that difficulty_data() strips off everything except .results and .ingredients. And it also needs to handle the special case "not (normal or expensive)" where you shove the whole recipe into it, but have to prevent stuff like .name, .type, etc from bleeding into the difficulty nodes, which reformat() doesn't do. And main_product defaults to nil so i'm not sure how to handle that within your "style". Also i noticed that you can't default "amount=1" because that would conflict with probability based recipes that use amound_min and amount_max instead.

I'm not sure if normalization should insert defaults. Finding things under the same property names in the same locations every time is useful. But missing properties take the default value so they are still "known" and since it's either there or not defined at all it is easier to manage the case where a property is missing. So currently I just dropped amount = 1.

For which recipe would .name etc end up in the difficulty nodes?

I'll take a look at the other things also later. Nice finds

[eradicator]

@OP i'm sorry for all the derailing. Maybe a friendly mod could split this off into a new "How to normalize a recipe in data stage." thread in modding help.

For better thread readability for future readers i'll put the non-coding bits of the discussion into a spoiler.

Personal discussion with Qon

What I meant to say was something more like a person can say "This is difficult to understand for me" while only a professional(/experienced) programmer is really qualified to say something like "this code is (objectivly) hard to understand and therefore bad and needs to be improved".

I see. Though i bet for many more complex pieces of code you can find two professionaly who disagree with each other.

For most code you shouldn't need the knowledge to understand a piece of code to use it

For abstract library code this might be true if it is properly maintained, tested and has been used for some time. For new code or code from unknown sources i need to understand it because i'm the one that'll have to maintain it.

You can compose composed functions too etc. B(f1, B(f2, f3)) or f1 . f2 . f3

Some quick googling told me that it's at least possible to build a multicomposer compose(f1,fk,...,fn) too. I just get "performance panic" when i see lots of function calls :p.

I'm not sure if normalization should insert defaults.

It makes it easier to later apply generic multiplication or conditionals without constantly having to check if the value exists at all. Because that kind of existance check is kinda the point of normalizing in the first place. Especially if we supposed that such a normalized recipe might not always be used as a new recipe, but is sometimes merely generated to easily check certain parameters of it to conditionally trigger something else. Hm...it does create the problem that later you can't tell anymore if a recipe explicitly defind something or if it's merely a default. So i'd say there's a usecase for both.

For which recipe would .name etc end up in the difficulty nodes?

For the not(normal or expensive) case *if* one used a generic reformat() on the whole recipe.
In your current version it doesn't happen becaues difficulty_data() completely strips off all flags. I.e. the output is incomplete.