23 Feb 01:13 2015

### GUI

I have finally found a bug causing Felix GUI code to crash on resizing a window.

It turns out this is a bug in SDL itself.

+1 to Felix. -1 to C.

--
john skaller
skaller@...
http://felix-lang.org

------------------------------------------------------------------------------
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE

13 Feb 15:25 2015

### Re: [felix] Interpreter


On 13/02/2015, at 3:40 PM, srean wrote:

> In that case let it be. enough of syntax bikeshedding :)

I do not have a good solution for low level loops at the moment.

I do think I have one for compact linear types though.

The problem with compact linear types at the moment is this:
Felix has a *principle* which says mutators require a pointer.
So

var x ...
&x <- v; // assignment

One reason for this is that it gets rid of lvalues as a concept.
More properly, it lays out very clear picture of the relationship
between values and objects, at least for product types.

Given a product object P with projection function j, then

val P = ..
j P = P.j

extracts the p component of a value and

var P = ...
(&P) . j



12 Feb 12:26 2015

### Re: [felix] Interpreter


On 12/02/2015, at 9:12 PM, srean wrote:

> Vim has syntax highlight files for M4 which has mismatched parenthesis.
>
> Felix allows range boundaries to be inclusive or exclusive and I quite like the [ ... ),
> ( ...], [ ...] and ( ... ) syntax for that.
>
> Web syntax  highlighters would probably break on these, vim does OK, I guess  Emacs would do fine too.

Plain ( ) [] would probably break all the tools and the parser
(in *any* combination, balanced or not).

I'm not sure about \left[ etc (the TeX notation).

--
john skaller
skaller@...
http://felix-lang.org

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

12 Feb 08:21 2015

### Re: [felix] Interpreter


On 12/02/2015, at 8:41 AM, Ryan Gonzalez wrote:

> I wrote a basic Pygments-based IDE in Python + Gtk+. Other than the fact it was really slow when pasting
text, it wasn't that bad. It highlighted Felix and Nim out-of-the-box.

Felix *.flx highlights are a bit tricky. My Vim stuff is an ugly mix of C and Python
hilighting code.

*.fdoc's are another story ;(

--
john skaller
skaller@...
http://felix-lang.org

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

11 Feb 21:48 2015

### Re: [felix] Interpreter


On 12/02/2015, at 12:57 AM, Shayne Fletcher wrote:

>
> On Wed, Feb 11, 2015 at 7:26 AM, john skaller <skaller <at> users.sourceforge.net> wrote:
> Ocaml lacks the ability for the end user to extend it.
>
> ​In the context of this discussion, I don't think that is entirely correct. As of 4.02, OCaml has
"extension points"​ (-ppx). See this post http://www.lexifi.com/blog/ppx-and-extension-points.
> t.

I do not like it at all. However, it is only a pre-processing feature.
It doesn't allow Ocaml code to be extended.

It's also a supreme hack, unreadable crud, all so Minsky could
continue to use his Emacs IDE (because it doesn't actually
change the Ocaml syntax). What Felix does is much better
and bad luck to IDE weanies with weak IDEs that can't be
extended. (I use Vim as a weak IDE and have no problem
extending it, but Ocaml IDE support often does a lot more
like mouse-overs showing function types).

Ocaml does have Dynload, which *does* allow extensions.

However Dynload has some serious limitations since it mandates
preservation of a rigid static typing system. It also requires having
an Ocaml compiler available. And it's only available with either
bytecode or on x86_64 processor with native code.


11 Feb 13:26 2015

### Re: [felix] Interpreter


On 10/02/2015, at 3:42 PM, Martin DeMello wrote:

> On Mon, Feb 9, 2015 at 2:56 PM, john skaller
> <skaller@...> wrote:
>>
>> I would actually like to rework the whole front end of the flxg
>> compiler in scheme. What I mean is that the core workhorse
>> algorithms would still be in Ocaml, but they'd be sequenced
>> by scheme code. OCS Scheme is written in Ocaml and allows
>> extra primitive procedures and data types written in Ocaml to
>
> What is the motivation behind that? OCaml strikes me as a much nicer
> language than scheme to write compilers in (much as I love scheme).

Ocaml lacks the ability for the end user to extend it.

On can't extend the Felix system by separately compiled
dynamically loaded plugins with Ocaml (at least not with the
is fairly restricted in scope.

At present a lot of constructions were added by me by just writing
a bit of grammar and some scheme that emitted some sequences
of existing terms. The compiler flxg just reads the grammar files
as part of the "library".

I picked scheme because



10 Feb 13:06 2015

### Re: [felix] Interpreter


On 10/02/2015, at 1:42 PM, Ryan wrote:
>
> Text editors with parenthesis highlighting really helps here.

Yep, I have that with Vim. It helps editing, but not reading :)

>> Python is procedural. It can't beat scheme, functional programming
>> technology
>> must be the core of any procedural language. Referential transparency
>> and
>> persistent data structures and all that.
>
> I thought Python was OO?

OO is a minor subset of procedural programming
of little real merit.  It was a nice idea but it was soon
proven to be too limited to be worth of serious consideration
in itself. A lot of the principles developed (encapsulation,
blah blah) are good, its just that OO either doesn't actually
provide them or does and fails to be expressive enough
for many uses.

Most Python people would say it is object based,
not object oriented.

However, really, dynamic languages aren't really serious
languages so it doesn't really matter what they are.

> I'd link the Stack Overflow answer about OO vs. functional by Norman Ramsey, but I'm too lazy to close my


10 Feb 01:37 2015

### Re: [felix] Interpreter


On 10/02/2015, at 10:16 AM, Ryan Gonzalez wrote:

> On Mon, Feb 9, 2015 at 4:56 PM, john skaller
<skaller@...> wrote:
>
> On 10/02/2015, at 6:24 AM, Ryan Gonzalez wrote:
>
> Lua is a bit of a hack I'm afraid, doesn't even parse cleanly.
>
> Because it beats Scheme!

Not really. Scheme is well designed ..

(not (grok syntax me))

Of course, the fact data is the same as code is a major plus
for meta-programming, and that basically fixes the syntax.
[It has to be simple .. I just hate all the parens because I have
a math degree but can't count :]

> As to Python, its the other way: no sense embedding Py in
> Felix, but you can use Felix to make Python modules for
> those unfortunate souls that have to write real applications
> using Python.

> Unless it's one of your favorite programming languages...
>
> People have implemented pattern matching in Python, and I'm working on a pattern matching library for Hy (Python+Lisp).
>


9 Feb 23:56 2015

### Re: [felix] Interpreter


On 10/02/2015, at 6:24 AM, Ryan Gonzalez wrote:

> Scheme is horrible, not hard.

[Because I can't :]

I am so used to pattern matching in Ocaml and Felix
I can't write the equivalent code in crap languages without
it any more (like Scheme .. C++ .. Python .. err ..)

So one big aim of the interpreter thing is to do pattern matching.
In particular with that .. the existing macro processor could probably
be thrown out.

In particular look at the grammar and especially

src/lib/grammar/grammar_scheme_support.fsyn

I would actually like to rework the whole front end of the flxg
compiler in scheme. What I mean is that the core workhorse
algorithms would still be in Ocaml, but they'd be sequenced
by scheme code. OCS Scheme is written in Ocaml and allows
extra primitive procedures and data types written in Ocaml to

One particular goal is that at the moment, I have managed to get
it so that literals and identifiers are actually lexed and parsed
IN the grammar, that is, the Dypgen+Scheme is actually used to


9 Feb 14:01 2015

### Interpreter

I am currently working on a small interpreter. Here is the idea:

At the moment, you can extend the grammar by specifying a production
in an EBNF like language and action codes in Scheme.

There are two problems with this: the first is that Scheme is hard to write,
at least for me. And the second is that the Scheme must return s-expressions
matching what the Felix compiler expects: the structure of these terms is
complex, there are a lot of them, and they're not properly documented.

To make it easier the parser supports an alternative method.

non-terminal := production =># "scheme code";l

you can write

non-terminal := production =># { Felix statements };
non-terminal := production =># ( Felix expression);

Only statements and expressions can be handled like this.

However, statements in particular are limited. For example
a custom loop like

stmt :=  "for" sname  "between" expr "and" expr "do" body =>#
{ var _2 = _4; ... ++_2; ... }

doesn't work because _2 is an sname, which is neither the correct
"part of speech" for a variable definition nor for an expression.


1 Feb 01:45 2015

### Re: [felix] packages


On 01/02/2015, at 10:56 AM, Ryan Gonzalez wrote:
>
> By consulting the history, the build date can be translated to the packages
> internal "version".
>
> Is this required for packages, or is it optional? Personally, I like the major.minor.fix scheme better.

It's just an idea. the major.minor.fix scheme has advantages, and on many
Linux (and other Unix) systems, it is enforced by the way links to
shared libraries are maintained.

The problem is that there is no coherent way to interlink such packages.
If packages depend on major.minor, then patches are irrelevant:
packages can be upgraded in isolation.

With major.minor the assumption is you need the same major (no other
will do) but any minor greater or equal to the specified one.

It's all a nice idea. But the reality of the world is continuous ad-hoc integration
and in that scenario the categorical distinctions of the package numbers
are useless UNLESS some human comes along and organises the
dependencies. This works with that, this can replace that, etc etc.

This is what Debian and Ubuntu and ArchLinux and all the other
package managers do and it is a HUGE effort which typically fails
most of the time. The last Debian release took over 2 years to get out.

Using a date YY.MM.DD defines your whole system with a single
number. Packages are comparable by date. They're NOT comparable