[ANN] GSL Shell new beta release with anti-gran graphics module

classic Classic list List threaded Threaded
126 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] GSL Shell new beta release with anti-gran graphics module

Sam Roberts
On Thu, Dec 3, 2009 at 1:58 PM, Francesco Abbate <[hidden email]> wrote:

> 2009/12/3 Sam Roberts <[hidden email]>:
>> Do you expect the gsl module to be useable independently of your
>> shell? The graphing capability in particular caught my attention.
>
> ENABLE_COMPLEX = yes
> BUILD_LUA_DLL = no
>
> To have a 100% orthodox GSL module you should build it by disable the
> complex number support and enable the build as a Lua DLL.
> Unfortunately if you disable complex numbers you will miss important
> submodules like FFT but other functions will be available. I recommend
> anyway to enable at least support for complex numbers.

Sorry, I've had lots of problems with LNUM before. Maybe it's better,
now, but I'm no longer a fan of hacking the interpreter.

And we are thinking of moving to Mike Pall's JIT, I don't think LNUM
is going to work with it.

Would complex support with a more portable, userdata-based approach
(like http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lcomplex) be too,
uh, complex?

There are some problems with the build system.

Empty strings are being passed on the g++ command line:

make DEFS='""' PLATFORM=linux -C agg-plot
make[1]: Entering directory `/home/sroberts/s/gslshell/trunk/agg-plot'
echo g++ -O2 "" -I.. -I../lua/src -I../lua/etc -I/usr/include/agg2 -c cplot.cpp
g++ -O2 "" -I.. -I../lua/src -I../lua/etc -I/usr/include/agg2
-Wp,-MMD,.deps/cplot.pp -c cplot.cpp

Root cause is your call to recursive make doesn't work with an empty
SUBDIRS_DEFS, which occurs in "DLL" builds (maybe rename this to
"MODULE", btw). I did this to fix it:

Index: Makefile
===================================================================
--- Makefile    (revision 35)
+++ Makefile    (working copy)
@@ -64,6 +64,7 @@
   CFLAGS += -fpic
   DEFS += -DUSE_SEPARATE_NAMESPACE
   TARGETS = $(LUA_DLL)
+  SUBDIRS_DEFS += -DNO_GSL_SHELL
 else
   SUBDIRS_DEFS += -DGSL_SHELL
   TARGETS = $(GSL_SHELL)

Personally, I wouldn't use a recursive make system:

http://miller.emu.id.au/pmiller/books/rmch/

Troubleshooting this was made more painful by the use of "@" in the
Makefiles, because the echoed cmd line looked fine, but the real one
wasn't fine. I did this:

Index: agg-plot/Makefile
===================================================================
--- agg-plot/Makefile   (revision 35)
+++ agg-plot/Makefile   (working copy)
@@ -64,18 +64,17 @@
        $(RANLIB) $@

 %.o: %.cpp
-       @echo $(CXXCOMPILE) -c $<
-       @$(CXXCOMPILE) -Wp,-MMD,.deps/$(*F).pp -c $<
-       @-cp .deps/$(*F).pp .deps/$(*F).P; \
+       $(CXXCOMPILE) -Wp,-MMD,.deps/$(*F).pp -c $<
+       -cp .deps/$(*F).pp .deps/$(*F).P; \
        tr ' ' '\012' < .deps/$(*F).pp \
           | sed -e 's/^\\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \
             >> .deps/$(*F).P; \
        rm .deps/$(*F).pp


Also, there is an architecture assumption. I think better by default
not to assume architecture, let people add extra optimization flags if
they want to:

Index: lua/src/Makefile
===================================================================
--- lua/src/Makefile    (revision 35)
+++ lua/src/Makefile    (working copy)
@@ -7,7 +7,7 @@
 # Your platform. See PLATS for possible values.
 PLATFORM = none

-CC= gcc --std=c99 -march=i586
+CC= gcc --std=c99
 CFLAGS= -g $(DEFS) $(MYCFLAGS)
 AR= ar rcu
 RANLIB= ranlib


And at the end I got this:

% lua -l gsl
lua: error loading module 'gsl' from file './gsl.so':
        ./gsl.so: undefined symbol: xwin_thread_function

No time to look further right now.


> There is also the higher file 'igsl.lua' that gives access to some
> basic facilities functions and it does depends on the |x| syntax. This
> shouldn't be a problem because this module's purpose is to serve the
> final user in the interactive shell and it is not needed to have
> access to core GSL functionalities.

Seems reasonable.

Cheers,
Sam
Reply | Threaded
Open this post in threaded view
|

Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Doug Rogers
In reply to this post by Norman Ramsey
Norman Ramsey wrote:
>  > And other line noise looks like line noise only if you've never seen C.
> Come on, David---be fair. ...
> I agree that Lua's goal is not to *maximize* information density.
> I believe Lua's goal is *appropriate* information density: there
> should be enough keywords to guide beginners, but for experts, there
> is not too much syntactic noise.  And I do think that in the case of
> anonymous functions, Lua's design is out of balance...

I'm with you, Norman. I would love to have a concise form for function
definition. I've found '|args|expr' to be beautiful and sufficient for
my experiments with gsl-shell; so much so that I miss it when I come
back to plain Lua, even when writing scripts or larger programs as
opposed to an interactive shell. If this particular form suffers from
ambiguities or surprises then perhaps some other form will work.

I can see David's point about adding precedence levels (implicitly or
not), but clearly there's a balance to be reached. My personal opinion
is that this syntactic sugar would be nearly as useful as the colon
operator - possibly more so for me. And I think Lua would remain in
balance with this feature.

I'm generally not a fan of adding features to Lua. I initially found
metatables (especially putting all the operator functions in them) to be
too much of an excessive change! I mean, why not just use prototyping
tables and explicitly fill them? (Don't answer that rhetorical question!)

The features I've really missed over the years are the bit-wise
operators, hexadecimal escape sequences, and hexadecimal numbers. It has
taken a long time, but now we have hexadecimal numbers. It looks like
we'll have bit-wise functions as a standard library in 5.2, possibly
even hexadecimal escape sequences. All are trivial - yet they *do* add
to the code base. I always applied a patch for these features because
they were so much of a benefit to my work, and the patch was so simple
that there was no question about where the balance tipped.

But we can all try this feature in our own way. Eventually the authors
will determine what goes in 5.2. Although I like this mod, I'm not
holding my breath for it.

The good news for you, David, is that the more verbose form will still
be available. And the good news for us is that, even if it is not in
5.2, it's easy enough to add. We just won't be able to share scripts.

But even that might not be true. If 5.2 includes a standard interface
for token filters, or for the components necessary for Metalua, then
there will be no more griping about simple syntax mods. We'll just use a
Lua-only module that provides the syntactic sugar we crave. (Yes, and we
might suffer the explosion of weird looking "code" seen in the abuse of
macros or templates.)

I apologize for the essay, but I wanted to add one more comment.

I've learned much from this list. I've also seen the authors themselves
grow as they have encountered new ideas from this mailing list (among
other places, of course). They've learned about proper lexical scoping
for proper closures, about how to make a VM that will operate more
quickly on modern CPUs, about properly encapsulating the Lua state, etc.
And along the way I think they were been bitten by the functional
programming bug.

That bug spreads a good kind of disease! I'm not a believer in the
mantra that all languages lead to LISP, but I do think that LISP's
simplicity (more than its proximity to lambda calculus) makes it a prime
environment in which to determine the *essential* elements of a
programming paradigm or feature. So there are many lessons to be learned
and many techniques to be applied by studying LISP, Scheme, Haskell, etc.

This proposed feature is just another one to be evaluated by them. But I
believe that the authors are in a better position now to determine
whether this form is worthy of inclusion in Lua proper, or whether some
even more general feature will be included that provides '|args|expr' as
a simple Lua add-on. Or neither. After all, there will eventually be a
Lua 6.0.

I'm willing to wait.

Doug

PS - The short post: +1

______________________________________________________________________________________
The information contained in this email transmission may contain proprietary and business
sensitive information.  If you are not the intended recipient, you are hereby notified that
any review, dissemination, distribution or duplication of this communication is strictly
prohibited.  Unauthorized interception of this e-mail is a violation of law.  If you are not
the intended recipient, please contact the sender by reply email and immediately destroy all
copies of the original message.

Any technical data and/or information provided with or in this email may be subject to U.S.
export controls law.  Export, diversion or disclosure contrary to U.S. law is prohibited.  
Such technical data or information is not to be exported from the U.S. or given to any foreign
person in the U.S. without prior written authorization of Elbit Systems of America and the
appropriate U.S. Government agency.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

steve donovan
On Fri, Dec 4, 2009 at 4:32 AM, Doug Rogers
<[hidden email]> wrote:
> But even that might not be true. If 5.2 includes a standard interface
> for token filters, or for the components necessary for Metalua, then
> there will be no more griping about simple syntax mods. We'll just use a
> Lua-only module that provides the syntactic sugar we crave. (Yes, and we
> might suffer the explosion of weird looking "code" seen in the abuse of
> macros or templates.)

Alas, but token filters have their limitations, because they operate
on the purely lexical level. |x|expr involves working out what an
'expr' is just from the tokens!  So Metalua is usually the tool of
choice for this kind of thing.  But there is a middle way; say there
was a new keyword 'lambda', so that we can say lambda(arglist) expr,
then a token filter could easily transform |x| into lambda(x).
Although a little more verbose, lambda involves one keyword, not
three, and is hence less noisy.  'Noise' is usually understood as a
random-looking set of characters (Perl and APL, you bet!) but could be
more broadly defined as anything that makes reading code more
difficult than it need be.  And nothing is taken away by adding such
short cuts, so people can continue to write in an idiom which they
consider to be 'classic Lua'

Statements like 'Lua is a procedural language' do not do it full
justice. Multiparadigm may be a buzzword, but it does apply here. The
functional style allows very elegant expression of common idioms,
which the short form helps.

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

David Kastrup
In reply to this post by Doug Rogers
Doug Rogers <[hidden email]> writes:

> Norman Ramsey wrote:
>>  > And other line noise looks like line noise only if you've never seen C.
>> Come on, David---be fair. ...
>> I agree that Lua's goal is not to *maximize* information density.
>> I believe Lua's goal is *appropriate* information density: there
>> should be enough keywords to guide beginners, but for experts, there
>> is not too much syntactic noise.  And I do think that in the case of
>> anonymous functions, Lua's design is out of balance...
>
> I'm with you, Norman. I would love to have a concise form for function
> definition. I've found '|args|expr' to be beautiful and sufficient for
> my experiments with gsl-shell;

gsl-shell is gsl-shell.

> so much so that I miss it when I come back to plain Lua, even when
> writing scripts or larger programs as opposed to an interactive
> shell. If this particular form suffers from ambiguities or surprises
> then perhaps some other form will work.
>
> I can see David's point about adding precedence levels (implicitly or
> not), but clearly there's a balance to be reached. My personal opinion
> is that this syntactic sugar would be nearly as useful as the colon
> operator - possibly more so for me. And I think Lua would remain in
> balance with this feature.
>
> I'm generally not a fan of adding features to Lua.

And this is not a feature.  It is an input transformation from an
insider shorthand to a more obvious form.  That's a downward spiral.

Now you are clamoring for a shorthand for
function (x) return x*x end
The next cry will be for a shorthand for
function (x) if x>0 then return 1 else return 0 end
because it would be soooooo convenient to write
|x| x>0 ? 1 : 0
and so forth and so on.

There is a price for functional line noise syntax in a procedural
language.  You end up completely replicating your control structures
with different syntax for "functional" use.

APL inside of Lua.  I repeat: Lua is a procedural language basing its
control flow on statements, not expressions.  Functional languages have
their own place and style.  If you want a functional language, use a
functional language.

> The good news for you, David, is that the more verbose form will still
> be available.

That's completely irrelevant unless I am not supposed to ever read code
written by other people.

Every "optional" language element needs to be learnt and read and
understood by anybody working with code from others.

I don't think that this kind of syntax fits well with the rest of Lua,
and I'd hate to have to teach beginners what it means exactly.

One major feature of Lua is that you can throw Lua code at unsuspecting
colleagues, and they can figure out what it does.  Line noise style
syntax may be concise, but it does not help people figure out things.

Lua has "and" and "or" instead of "||" and "&&", and that

> But even that might not be true. If 5.2 includes a standard interface
> for token filters, or for the components necessary for Metalua, then
> there will be no more griping about simple syntax mods. We'll just use
> a Lua-only module that provides the syntactic sugar we crave.

With multiple people using multiple incompatible syntactic sugar.

> And along the way I think they were been bitten by the functional
> programming bug.
>
> That bug spreads a good kind of disease! I'm not a believer in the
> mantra that all languages lead to LISP, but I do think that LISP's
> simplicity (more than its proximity to lambda calculus) makes it a
> prime environment in which to determine the *essential* elements of a
> programming paradigm or feature.

So program in LISP.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Robert Raschke
In reply to this post by steve donovan
As far as I can see Lua is first and foremost an embeddable scripting language. That it is useful as a programming language in its own right is down to the clean design of the language, and the ease with which third-party libraries can be incorporated.

For myself, the major success of Lua lies with its focus on configuration. The ability to use the Lua syntax with additional functions and values defined by myself to create a domain specific configuration language that is easy to create, use, implement and roll out the door.

Functional programming languages are great and I use them all the time (SML, Erlang, J, Haskell, Scheme), but these are not great for solving my problem of configuration (never mind C, Java, etc.). Yes, I can do it it any of them, but not with as much fun!

Sine Lua is so easily embeddable (and allows other stuff to be embedded within itself), why not go all out multi-paradigm and glue together some languages? Allow calling into Haskell from Lua, make Lua callable from Haskell. Have a nice boundary between the two systems that allows you to use the appropriate technology for your problem. Don't create the one true language! Use them all!

And, no, I've not felt constrained by function (x) return x*x end instead of \x->x*x so far.

Robby

Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

Miles Bader-2
In reply to this post by David Kastrup
David Kastrup <[hidden email]> writes:
> I don't think that this kind of syntax fits well with the rest of Lua,

That's what it comes down to -- taste.  You don't like it.  Other people do.

-Miles

--
Selfish, adj. Devoid of consideration for the selfishness of others.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

Thomas Lauer-3
Miles Bader <[hidden email]> wrote:
----original message----
From: Miles Bader <[hidden email]>
Date: Fri, 04 Dec 2009 18:20:20 +0900
Subj: Re: Short function definition syntax; thoughts on Lua
> David Kastrup <[hidden email]> writes:
> > I don't think that this kind of syntax fits well with the rest of Lua,
>
> That's what it comes down to -- taste.  You don't like it.  Other people do.

If *IT* is really just a matter of taste, *IT* should probably not be
implemented.

I have always been of the opinion that to save typing a few more
characters is not a priority in language design. A good editor goes a
long way.

--
cheers  thomasl

web: http://thomaslauer.com/start
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

steve donovan
On Fri, Dec 4, 2009 at 11:51 AM, Thomas Lauer <[hidden email]> wrote:
> If *IT* is really just a matter of taste, *IT* should probably not be
> implemented.

Well, that argument cuts in other ways. 'function fun(x) .. end' is
just sugar for 'fun = function(x) ... end', it isn't strictly
necessary.

> I have always been of the opinion that to save typing a few more
> characters is not a priority in language design. A good editor goes a
> long way.

Oh sure, any half-decent editor can expand an abbreviation, it's not
about typeability, but readability. For instance, people use 'map'
functions not really because they can't be bothered to type for-loops,
but they want to concisely and clearly express what they are doing.
It's not about APL-style compression.

There is the statement that 'newbies will find it confusing'.  Well,
any newbie was doing mathematical calculations will quickly get that
to plot a function one just passes something like '|x| x*(x-1)'.  In
fact, I wager that a person from a procedural background would choke
over the long form, because of the prejudice that _functions are
statements_.

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Luiz Henrique de Figueiredo
In reply to this post by steve donovan
> But there is a middle way; say there was a new keyword 'lambda', so
> that we can say lambda(arglist) expr, then a token filter could easily
> transform |x| into lambda(x).

Why 'lambda' when 'function' exists and works just as well?
And one possible syntax could be
        function (x,y,z)=x+y*z
which is reminiscent of Fortran one-line function statements except that
defines anonymous functions.

This syntax is even friendlier to token filters because you only need to
convert '=' to 'return' but the real problem is of course how to detect
the end of the expression so that 'end' can be added.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

David Kastrup
In reply to this post by Miles Bader-2
Miles Bader <[hidden email]> writes:

> David Kastrup <[hidden email]> writes:
>> I don't think that this kind of syntax fits well with the rest of Lua,
>
> That's what it comes down to -- taste.  You don't like it.

Oh, it's fine in Haskell.  Really wonderful.  I like it where it
belongs.

I like sed.  I like awk.  I like C.  I don't like perl which appears to
be based on the premise "let us accept input looking like sed scripts,
input looking like awk scripts, input looking like C".  I hate that.
Ruby goes down similar roads.  I like Ada generics and their syntax
fitting within the framework of Ada's constraint syntax.  I hate how C++
adopted them as "templates" without bothering to even match the syntax
to C.  The syntax clashes with << and >> operators, for example.

I like Scheme and Lisp to a certain degree (even though nobody actually
programs functionally in them, set!/setq being all over the place).

The one thing that really struck me about Lua is that Lua programs looks
like Lua.  They don't go fancy-syntax fishing elsewhere.  That's kind of
unusual for a script language nowadays.

> Other people do.

Good thing not everybody and the world has commit access, then.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

Miles Bader-2
In reply to this post by Thomas Lauer-3
Thomas Lauer <[hidden email]> writes:
> I have always been of the opinion that to save typing a few more
> characters is not a priority in language design. A good editor goes a
> long way.

It has more to do with making code easy to _read_ than easy to type.

That _is_ a priority in language design.

[Whether it accomplishes that goal is the area of contention, of
course -- David does not think so (in fact he thinks it does the
opposite), whereas other people think it does.  YMMV.]

-Miles

--
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

Miles Bader-2
In reply to this post by David Kastrup
David Kastrup <[hidden email]> writes:
> The one thing that really struck me about Lua is that Lua programs looks
> like Lua.  They don't go fancy-syntax fishing elsewhere.  That's kind of
> unusual for a script language nowadays.

I agree, in general -- I like Lua syntax, and I don't like things like
attempts to sneak in C-bracey syntax extensions I've seen in the past.

But I think the || syntax for very short anonymous functions is fine.

Just because Lua is, in general, a very "keywordy" language, doesn't
mean it has to _completely_ eschew punctuation -- it uses "+" for
addition after all :) -- and I view || as being exactly in that same
vein, a short expression-oriented syntax, whose main goal is brevity.

[FWIW, I'd also like an ?: operator for in-expression if-else...]

-Miles

--
Monday, n. In Christian countries, the day after the baseball game.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

steve donovan
In reply to this post by Luiz Henrique de Figueiredo
On Fri, Dec 4, 2009 at 12:12 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>        function (x,y,z)=x+y*z
> which is reminiscent of Fortran one-line function statements except that
> defines anonymous functions.

But it looks like an assignment...

The word 'lambda' has a long history, as long as function probably. A
new keyword because it's so awkward to find end-of-expression without
help from the parser.

Was thinking about Fortran one-line functions in the context of 'short
form' anonymous functions, as an example of an extra optional feature
which does little harm.

> This syntax is even friendlier to token filters because you only need to
> convert '=' to 'return' but the real problem is of course how to detect
> the end of the expression so that 'end' can be added.

This is precisely the problem for lexical solutions.

I confess to being a little puzzled at why people get so excited about
the short form. It's just a convenient abbreviation, a little bit of
sugar.  Neither does it establish a precedent, since the Lua authors
have never been known to be railroaded into _anything_ they didn't
like ;)

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua

David Kastrup
In reply to this post by steve donovan
steve donovan <[hidden email]> writes:

> On Fri, Dec 4, 2009 at 11:51 AM, Thomas Lauer <[hidden email]> wrote:
>> If *IT* is really just a matter of taste, *IT* should probably not be
>> implemented.
>
> Well, that argument cuts in other ways. 'function fun(x) .. end' is
> just sugar for 'fun = function(x) ... end', it isn't strictly
> necessary.

But wouldn't it feel inconsistent to have a shorthand for
function(x) return x*x end
but not for
function(x) if x>0 then return 1 else return 0 end end

When you write a program and half the anonymous functions look like |x|
x*x and the other utterly differently?

Wouldn't maintaining that elegance require that you get expression
shorthands for most control structures in use for "short functions"?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Peter Sommerfeld-2
In reply to this post by steve donovan
steve donovan::
> Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
>>        function (x,y,z)=x+y*z
>> which is reminiscent of Fortran one-line function statements except that
>> defines anonymous functions.
>
> But it looks like an assignment...

function (x,y,z) -> x+y*z

Hallo Erlang! Looks like return.

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Luiz Henrique de Figueiredo
> function (x,y,z) -> x+y*z

Except that '->' looks really ugly in the fonts I use because '-' and '>'
are not aligned at the middle.

We might as well go for the traditional lambda notation :-)
        \x,y,z.x+y*z

With mandatory parentheses, this is amenable to token filtering...
        \x,y,z.(x+y*z)
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Paul Hudson-2
In reply to this post by steve donovan
I confess to being a little puzzled at why people get so excited about
the short form. It's just a convenient abbreviation, a little bit of
sugar.

Because, for Lua in particular, there is a resistance to convenience and sugar. Not a refusal to ever consider it, but Lua is remarkably free of cruft and I for one would prefer it stayed that way.

lambda would be OK if you are familiar with the lambda calculus and/or Lisp etc. I suspect that's actually a tiny proportion of the Lua user base (although it includes me), and for the rest it will be just a wacky and confusing term.

Paul
/bring bar car and cadr.
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

Peter Sommerfeld-2
In reply to this post by Luiz Henrique de Figueiredo
>> function (x,y,z) -> x+y*z
>
> Except that '->' looks really ugly in the fonts I use because '-' and '>'
> are not aligned at the middle.

That's no reason, - take another font! :-)

Actually, I think this would be the best
solution for non-math types like me.

Peter

Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

steve donovan
In reply to this post by Luiz Henrique de Figueiredo
On Fri, Dec 4, 2009 at 1:36 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> With mandatory parentheses, this is amenable to token filtering...
>        \x,y,z.(x+y*z)

Yes, that looks good (although obviously a matter of opinion ;))

BTW, is there any position yet on token filtering being part of Lua 5.2?
Reply | Threaded
Open this post in threaded view
|

Re: Short function definition syntax; thoughts on Lua (was Re: [ANN] GSL Shell new beta release...)

David Given
In reply to this post by Paul Hudson-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Hudson wrote:
[...]
> Because, for Lua in particular, there is a resistance to convenience and
> sugar. Not a refusal to ever consider it, but Lua is remarkably free of
> cruft and I for one would prefer it stayed that way.

Yup. There are, AFAIK, precisely two bits of syntactic sugar in Lua ---
: notation for calling functions, and 'local function' for defining
them. And even the first isn't really sugar, as it generates specific
bytecode that you can't generate elsewhere.

I'm like you in that I don't think Lua should get these syntax
extensions. I want it small and simple and with only one way of doing
anything. It is entirely feasible, and indeed quite easy, to write your
own language translator into Lua and bolt it into the require system
(I'm doing that for Objective Lua (release Real Soon Now!) and it works
very well).

So if people want functional syntax, design a *proper* functional
language syntax from the ground up and translate it into Lua. That way
you get other functional things like everything-is-an-expression, etc.
Most functional languages have simple syntaxes that are easy to parse, too.

(Although this isn't a democracy, and the language devs have the only
opinion that matters, and quite rightly ignore all the periodic
discussione of 'I-want-$FEATURE'... I will say that I'd be very happy if
they could consider adding #line support. Right now generating Lua is a
pain because in order to get the debug information right we have to do
it all in order. That is, the generated code for line 7 of the source
file must exist on line 7 of the output Lua file, and woe betide you if
you want to generate the code for line 8 of the source file on line 6 of
the output file. It's annoyingly restrictive, particular when you need
to clump related bits of code together to take advantage of the lexical
scoping.)

- --
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksY+/8ACgkQf9E0noFvlzjQ2ACfdSBmw799DNrdZxvnOI2eHuDq
c0QAmwbUi1BQHr4wwOVoVQUWY9sk5syp
=IzNK
-----END PGP SIGNATURE-----
1234567