librelist archives

« back to archive

Keeping the spirit (or not)

Keeping the spirit (or not)

From:
Danko Alexeyev
Date:
2012-05-15 @ 10:25
Hi,

I've just discovered Efene recently so I haven't even got a snippet to 
show yet. But I'm working on it )

What I wanted to know is, how do you see the future of Efene? Should it 
stay just a preprocessor (a nice one, though) or add some higher level 
features?

Efene _looks_ like an imperative language now, but deep down it's still 
Erlang, with all it's functional limitations, which are probably nice 
and all, but when we're talking about productivity and readability, I do 
want my good ol' imperative stuff.

You know, if without else, mutable variables, loops, and, worst of them 
all, the return statement.

All of that _can_ be done on a preprocessor level efficiently (but it 
might need another rewrite, I haven't looked at the code yet). The 
question is - do _you_ (Mariano) think it should be done?

-- 
Best regards,

Danko Alexeyev,
VeryPositive

+371 2648 3953
danko@very.lv
Skype: d.alexeyev

Re: [efene] Keeping the spirit (or not)

From:
Mariano Guerra
Date:
2012-06-24 @ 10:03
On Tue, May 15, 2012 at 12:25 PM, Danko Alexeyev <danko@very.lv> wrote:
> Hi,

hi, sorry for the delay.

> I've just discovered Efene recently so I haven't even got a snippet to
> show yet. But I'm working on it )

great!

> What I wanted to know is, how do you see the future of Efene? Should it
> stay just a preprocessor (a nice one, though) or add some higher level
> features?

it has some features not present on erlang, but the idea is to keep it
as close to erlang as possible in terms of semantics.

> Efene _looks_ like an imperative language now, but deep down it's still
> Erlang, with all it's functional limitations, which are probably nice
> and all, but when we're talking about productivity and readability, I do
> want my good ol' imperative stuff.
>
> You know, if without else, mutable variables, loops, and, worst of them
> all, the return statement.

about if without else, in erlang everything is an expression, if I
implement if without else then the else should return something to
avoid a bad_match exception, in taht case, what would that be? maybe
returning nil or no_clause would work, what do you think?

mutable variables is something I've been thinking about, of course,
just mutable inside a function and not actually mutable but making it
seem that they are mutable by having some special syntax and adding
prefixes to the variable when compiling since the erlang VM doesn't
allow mutable variables.

about loops, you have the for loop
(http://marianoguerra.org/efene/docs/reference/expressions/for.html)
which is similar to the python for loop, of course, under the hood is
a list comprehensions so you have all the features of that.

about the return statement, I don't think it can be implemented at the
level where efene is implemented, why would you want a return
statement anyway? I never needed it since I'm coding in erlang/efene
and I come from languages like C,Python,Js etc.

> All of that _can_ be done on a preprocessor level efficiently (but it
> might need another rewrite, I haven't looked at the code yet). The
> question is - do _you_ (Mariano) think it should be done?

my answers are above, let me know what you think.

Re: [efene] Keeping the spirit (or not)

From:
Roman Pelvetsky
Date:
2012-05-16 @ 21:31
Hi Danko,
What is the point of making mutable assignments in functional language?
It will not speed up anything just introduce another group of possible
errors which could be made by programmer.

'Good old' imperative things are the legacy of dynosaurs epoch and
that things are not actually any good at all :)

Cheers, Roman

Re: [efene] Keeping the spirit (or not)

From:
Danko Alexeyev
Date:
2012-05-17 @ 05:09
Hi Roman,

I cannot remember myself making any serious errors related to mutable 
assignments (or any of the other things I listed). And mind you, I code 
in PHP most of the time, that thing reacts to forkups in most unpleasant 
ways (it doesn't). What I do remember is making (runtime!) errors in 
Erlang because of using the wrong intermediary variable while 
constructing proplists and similar stuff.

Of course, most of the dinosaurs' problems can be solved with a chain of 
functions in Erlang, but I prefer a language that doesn't impose 
limitations on my code structure for no particular reason but because it 
could maybe possibly help me avoid mystical potential errors. I *love* 
Erlang for most of it's features, but that isn't one of them.

It's not like I'm asking for all of the imperative stuff. No, most of 
that is bad and does indeed lead to errors, but not the things I listed.

So as for your remark that "It will not speed up anything", I beg to 
differ, it will speed up just the most important thing in language 
design - the programmer(s). It will also speed up language adoption - if 
Efene has that stuff, I promise to convert all my staff to it by the end 
of the year.

But I really, honestly want them to be able to do something like this:

fun what(Something) {
	
	// Another hypothetical syntax sugar for switch
	match ((yep, Value) = i_know_the_value_for(Something)) {
		return Value
	}

	&Stuff = { always_here : yeah }

	if (Something.important == quite_a_bit) {
		&Stuff = &Stuff.might_sometimes_be_set := "or not" }
	}

	//Added a month later
	&Stuff.a = default_value

	for (Atom in [a, list, of, atoms]) {
		match ({yep, AtomValue} = some_check_about(Atom)) {
			&Stuff = &Stuff.Atom := AtomValue
		}
	}

	&Stuff

}

Add all else-s, replace &Stuff with corresponding StuffN or 
StuffAfterThatThing, replace for with a foldl and you _might_ see my 
point. (Or not)

-- 
Best regards,

Danko Alexeyev,
VeryPositive

+371 2648 3953
danko@very.lv
Skype: d.alexeyev


P.S. If this is rejected, I'll make a fork and call it "profane 
programming language"