Question is in the title, really. I saw someone use this earlier and I didn't know what the ! was used for.
local lowestIndex = 0;
local lowestValue = false;
for k, v in ipairs(playerElement) do
if !lowestValue or v.value < lowestValue then
lowestIndex = k;
lowestValue = v;
end
end
As others have said, ! normally has no function in Lua, and the code you posted would not normally be valid. However, it's quite trivial to extend Lua's parser to allow for custom syntax, and it's not unheard of for projects which embed Lua to add "more familiar" C-style syntax such as !var and != in addition to not var and ~=. One notable project which does this is Garry's Mod, and I'm sure there are others.
Of course, using custom syntax when the normal syntax is available (or customising it in the first place) is best avoided, if possible, to avoid exactly this sort of confusion.
It's a syntax error.
Some languages, mostly C and its relatives, use ! as a logical "not" operator, but Lua uses the not keyword instead, and does not use ! for anything as far as I know (not even as part of the inequality operator; it uses ~= where C uses !=).
You appear to have gotten hold of some Lua code written by someone who doesn't know that.
Related
I see use experimental 'postderef' being used in Moxie here on line 8. I'm just confused at what it does. The man pages for experimental are pretty vague too,
allow the use of postfix dereferencing expressions, including in interpolating strings
Can anyone show what you would have to do without the pragma, and what the pragma makes easier or possible?
What is it
It's simple. It's syntactic sugar with ups and downs. The pragma is no longer needed as the feature is core in 5.24. But in order for the feature to be supported in between 5.20 and 5.24, it had to be enabled with: use experimental 'postderef'. In the provided example, in Moxie, it's used in one line which has $meta->mro->#*; without it you'd have to write #{$meta->mro}.
Synopsis
These are straight from D Foy's blog, along with Idiomatic Perl for comparison that I've written.
D Foy example Idiomatic Perl
$gimme_a_ref->()->#[0]->%* %{ $gimme_a_ref->()[0] }
$array_ref->#* #{ $array_ref }
get_hashref()->#{ qw(cat dog) } #{ get_hashref() }{ qw(cat dog) }
These examples totally provided by D Foy,
D Foy example Idiomatic Perl
$array_ref->[0][0]->#* #{ $array_ref->[0][0] }
$sub->&* &some_sub
Arguments-for
postderef allows chaining.
postderef_qq makes complex interpolation into scalar strings easier.
Arguments-against
not at all provided by D Foy
Loses sigil significance. Whereas before you knew what the "type" was by looking at the sigil on the left-most side. Now, you don't know until you read the whole chain. This seems to undermine any argument for the sigil, by forcing you to read the whole chain before you know what is expected. Perhaps the days of arguing that sigils are a good design decision are over? But, then again, perl6 is still all about them. Lack of consistency here.
Overloads -> to mean, as type. So now you have $type->[0][1]->#* to mean dereference as $type, and also coerce to type.
Slices do not have an similar syntax on primitives.
my #foo = qw/foo bar baz quz quuz quuuz/;
my $bar = \#foo;
# Idiomatic perl array-slices with inclusive-range slicing
say #$bar[2..4]; # From reference; returns bazquzquuz
say #foo[2..4]; # From primitive; returns bazquzquuz
# Whizbang thing which has exclusive-range slicing
say $bar->#[2,4]; # From reference; returns bazquz
# Nothing.
Sources
Brian D Foy in 2014..
Brian D Foy in 2016..
4> abs(1).
1
5> X = abs.
abs
6> X(1).
** exception error: bad function abs
7> erlang:X(1).
1
8>
Is there any particular reason why I have to use the module name when I invoke a function with a variable? This isn't going to work for me because, well, for one thing it is just way too much syntactic garbage and makes my eyes bleed. For another thing, I plan on invoking functions out of a list, something like (off the top of my head):
[X(1) || X <- [abs, f1, f2, f3...]].
Attempting to tack on various module names here is going to make the verbosity go through the roof, when the whole point of what I am doing is to reduce verbosity.
EDIT: Look here: http://www.erlangpatterns.org/chain.html The guy has made some pipe-forward function. He is invoking functions the same way I want to above, but his code doesn't work when I try to use it. But from what I know, the guy is an experienced Erlang programmer - I saw him give some keynote or whatever at a conference (well I saw it online).
Did this kind of thing used to work but not anymore? Surely there is a way I can do what I want - invoke these functions without all the verbosity and boilerplate.
EDIT: If I am reading the documentation right, it seems to imply that my example at the top should work (section 8.6) http://erlang.org/doc/reference_manual/expressions.html
I know abs is an atom, not a function. [...] Why does it work when the module name is used?
The documentation explains that (slightly reorganized):
ExprM:ExprF(Expr1,...,ExprN)
each of ExprM and ExprF must be an atom or an expression that
evaluates to an atom. The function is said to be called by using the
fully qualified function name.
ExprF(Expr1,...,ExprN)
ExprF
must be an atom or evaluate to a fun.
If ExprF is an atom the function is said to be called by using the implicitly qualified function name.
When using fully qualified function names, Erlang expects atoms or expression that evaluates to atoms. In other words, you have to bind X to an atom: X = atom. That's exactly what you provide.
But in the second form, Erlang expects either an atom or an expression that evaluates to a function. Notice that last word. In other words, if you do not use fully qualified function name, you have to bind X to a function: X = fun module:function/arity.
In the expression X=abs, abs is not a function but an atom. If you want thus to define a function,you can do so:
D = fun erlang:abs/1.
or so:
X = fun(X)->abs(X) end.
Try:
X = fun(Number) -> abs(Number) end.
Updated:
After looking at the discussion more, it seems like you're wanting to apply multiple functions to some input.
There are two projects that I haven't used personally, but I've starred on Github that may be what you're looking for.
Both of these projects use parse transforms:
fun_chain https://github.com/sasa1977/fun_chain
pipeline https://github.com/stolen/pipeline
Pipeline is unique because it uses a special syntax:
Result = [fun1, mod2:fun2, fun3] (Arg1, Arg2).
Of course, it could also be possible to write your own function to do this using a list of {module, function} tuples and applying the function to the previous output until you get the result.
I was wondering if there is a general convention for the usage of semicolons in Lua, and if so, where/why should I use them? I come from a programming background, so ending statements with a semicolon seems intuitively correct. However I was concerned as to why they are "optional" when its generally accepted that semicolons end statements in other programming languages. Perhaps there is some benefit?
For example: From the lua programming guide, these are all acceptable, equivalent, and syntactically accurate:
a = 1
b = a*2
a = 1;
b = a*2;
a = 1 ; b = a*2
a = 1 b = a*2 -- ugly, but valid
The author also mentions: Usually, I use semicolons only to separate two or more statements written in the same line, but this is just a convention.
Is this generally accepted by the Lua community, or is there another way that is preferred by most? Or is it as simple as my personal preference?
Semi-colons in Lua are generally only required when writing multiple statements on a line.
So for example:
local a,b=1,2; print(a+b)
Alternatively written as:
local a,b=1,2
print(a+b)
Off the top of my head, I can't remember any other time in Lua where I had to use a semi-colon.
Edit: looking in the lua 5.2 reference I see one other common place where you'd need to use semi-colons to avoid ambiguity - where you have a simple statement followed by a function call or parens to group a compound statement. here is the manual example located here:
--[[ Function calls and assignments can start with an open parenthesis. This
possibility leads to an ambiguity in the Lua grammar. Consider the
following fragment: ]]
a = b + c
(print or io.write)('done')
-- The grammar could see it in two ways:
a = b + c(print or io.write)('done')
a = b + c; (print or io.write)('done')
in local variable and function definition. Here I compare two quite similar sample codes to illustrate my point of view.
local f; f = function() function-body end
local f = function() function-body end
These two functions can return different results when the function-body section contains reference to variable "f".
Many programming languages (including Lua) that do not require semicolons have a convention to not use them, except for separating multiple statements on the same line.
Javascript is an important exception, which generally uses semicolons by convention.
Kotlin is also technically an exception. The Kotlin Documentation say not only not to use semicolons on non-batched statements, but also to
Omit semicolons whenever possible.
In local variable definitions, we get ambiguous results from time to time:
local a, b = string.find("hello world", "hello") --> a = nil, b = nil
while sometimes a and b are assigned the right values 7 and 11.
So I found no choice but to follow one of these two approaches:
local a, b; a, b = string.find("hello world", "hello") --> a, b = 7, 11
local a, b
a, b = string.find("hello world", "hello") --> a, b = 7, 11
For having more than one thing on a line, for example:
c=5
a=1+c
print(a) -- 6
could be shortened to:
c=5; a=1+c; print(a) -- 6
also worth noting that if you're used to Javascript, or something like that, where you have to end a line in a semicolon, and you're especially used to writing that, then this means that you won't have to remove that semicolon, and trust me, i'm used to Javascript too, and I really, really forget that you don't need the semicolon, every time I write a new line!
Is there a good reason why the type of Prelude.read is
read :: Read a => String -> a
rather than returning a Maybe value?
read :: Read a => String -> Maybe a
Since the string might fail to be parseable Haskell, wouldn't the latter be be more natural?
Or even an Either String a, where Left would contain the original string if it didn't parse, and Right the result if it did?
Edit:
I'm not trying to get others to write a corresponding wrapper for me. Just seeking reassurance that it's safe to do so.
Edit: As of GHC 7.6, readMaybe is available in the Text.Read module in the base package, along with readEither: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Text-Read.html#v:readMaybe
Great question! The type of read itself isn't changing anytime soon because that would break lots of things. However, there should be a maybeRead function.
Why isn't there? The answer is "inertia". There was a discussion in '08 which got derailed by a discussion over "fail."
The good news is that folks were sufficiently convinced to start moving away from fail in the libraries. The bad news is that the proposal got lost in the shuffle. There should be such a function, although one is easy to write (and there are zillions of very similar versions floating around many codebases).
See also this discussion.
Personally, I use the version from the safe package.
Yeah, it would be handy with a read function that returns Maybe. You can make one yourself:
readMaybe :: (Read a) => String -> Maybe a
readMaybe s = case reads s of
[(x, "")] -> Just x
_ -> Nothing
Apart from inertia and/or changing insights, another reason might be that it's aesthetically pleasing to have a function that can act as a kind of inverse of show. That is, you want that read . show is the identity (for types which are an instance of Show and Read) and that show . read is the identity on the range of show (i.e. show . read . show == show)
Having a Maybe in the type of read breaks the symmetry with show :: a -> String.
As #augustss pointed out, you can make your own safe read function. However, his readMaybe isn't completely consistent with read, as it doesn't ignore whitespace at the end of a string. (I made this mistake once, I don't quite remember the context)
Looking at the definition of read in the Haskell 98 report, we can modify it to implement a readMaybe that is perfectly consistent with read, and this is not too inconvenient because all the functions it depends on are defined in the Prelude:
readMaybe :: (Read a) => String -> Maybe a
readMaybe s = case [x | (x,t) <- reads s, ("","") <- lex t] of
[x] -> Just x
_ -> Nothing
This function (called readMaybe) is now in the Haskell prelude! (As of the current base -- 4.6)
I'm getting stymied by the way "dot notation" works with objects and records when trying to program in a point-free functional style (which I think is a great, concise way to use a functional language that curries by default).
Is there an operator or function I'm missing that lets me do something like:
(.) object method instead of object.method?
(From what I was reading about the new ? operator, I think it works like this. Except it requires definition and gets into the whole dynamic binding thing, which I don't think I need.)
In other words, can I apply a method to its object as an argument like I would apply a normal function to its argument?
Short answer: no.
Longer answer: you can of course create let-bound functions in a module that call a method on a given type... For example in the code
let l = [1;2;3]
let h1 = l.Head
let h2 = List.hd l
there is a sense in which "List.hd" is the version of what you want for ".Head on a list". Or locally, you can always do e.g.
let AnotherWay = (fun (l:list<_>) -> l.Head)
let h3 = AnotherWay l
But there is nothing general, since there is no good way to 'name' an arbitrary instance method on a given type; 'AnotherWay' shows a way to "make a function out of the 'Head' property on a 'list<_>' object", but you need such boilerplate for every instance method you want to treat as a first-class function value.
I have suggested creating a language construct to generalize this:
With regards to language design
suggestions, what if
SomeType..Foo optArgs // note *two* dots
meant
fun (x : SomeType) -> x.Foo optArgs
?
In which case you could write
list<_>..Head
as a way to 'functionize' this instance property, but if we ever do anything in that arena in F#, it would be post-VS2010.
If I understand your question correctly, the answer is: no you can't. Dot (.) is not an operator in F#, it is built into the language, so can't be used as function.