clauderoux

:-)

You have revealed my true identity...

If you have a look on the page, you'll see that I do worse. I also provide a French version (VO) of the article.

Actually, since English borrowed many spelling convention from French, and then invented quite a few for itself, I find it quite ridiculous to say that French is worse than English. In French, pronunciations is usually not an issue, the rules are quite straightforward and quite regular, despite what you may think. Grammar is pretty complicated, but it is very very rare to have words in French for which people might wonder what is the actual pronunciation. Usually, the problem will only arise for words borrowed from a foreign language with a foreign spelling.

What you say doesn't make any sense. As part of the EU, European citizens had the right to move to any countries of their choice. This was the very definition of being part of the EU. British nationals could move to any European countries, which they did in flock, and European nationals could also move to UK. South Africa was a third country, to which EU laws did not apply, hence their difference in treatment by the UK. The UK was part of a huge ensemble in which people could feely move from one place to another, it is no longer the case.

Yes, good idea. I don't think it would be that complicated... Actually, the language already exposes a "split" method that can be used exactly for that.

I have been interested for years in Data Programming, a weird expression coined by Christopher Ré (PR at Stanford). Basically, the idea is to be able to automatically apply filters on your data before building your model in an ML pipeline. This version of Lisp comes with data structures and pattern matching expressions, to detect some regular patterns in your data... This is the reason why we also have implemented a Python library so that your sieves can be called from within your Python code beforehand.

By the way, I have updated tamgusys.h to integrate mouse support in Windows consoles...

Of course, you are right. However, tamgucalc launches instantly in your terminal, which is not always the case for emacs, which is sometimes a bit to slow.

Furthermore, this spreadsheet is fully "libre", you can modify it and transform it according to your needs. There is also the possibility to write "regular formulas", which are more similar to what people are used to.

I fully agree with you. When you see how cumbersome Excel formulas can be when you want to mix different operators together, with their "(",";" and so on and so forth. I wonder how you can say that Lisp is too verbose for this task.

Actually, I have another private GitHub, where I do most of my experiments and which is bit more informative. When my code executes, I then push it on the official one, hence the lack of comments.

please accept my apologies, I should be more verbose in my comments. The whole implementation is in tamgusys.cxx. See inmouse and outmouse for more details. Basically, inmouse activates the mouse catching events, which are sent through getchar. Once, the mouse has been activated, you can use some primitives mouedown1 our mouseup, which takes as input the string returned by getchar and returns the x,y coordinates

you might want to try this one: https://github.com/naver/tamgu/wiki/7.-Lisp-Interpreter

In the case of Latin, the word for fox is vulpus, which is a direct evolution of the indo-european root. In this case, the problem is less of a taboo word than of an appropriation of the sense to a different animal.

We do not talk about reality anymore. This is so 20th century stuff... We talk about alternate facts...

In my lab, we use more and more a programming language such as tamgu, which has been implemented to benefit from pipes with an integrated editor. (https://github.com/naver/tamgu/blob/master/docs/English/tamg...)

In https://github.com/naver/tamgu/blob/master/include/conversio..., I have implemented a class: agnostring which derives from "std::string".

There are some methods to traverse a UTF8 string:

  begin(): to initialize the traversal
  end() : is true when the string is fully traversed
  next(): which goes to the next character and returns the current character.


  s.begin();
  while (!s.end()) {
    u = s.next();
  }

You can have a look on: s_is_emoji...

Exactly my point. Most modern emojis cannot rely on pure codepoints to be extracted.

We went through a lot of pain to get this right in Tamgu (https://github.com/naver/tamgu). In particular, emojis can be encoded across 5 or 6 Unicode characters. A "black thumb up" is encoded with 2 Unicode characters: the thumb glyph and its color.

This comes at a cost. Every time you extract a sub-string from a string, you have to scan it first for its codepoints, then convert character positions into byte positions. One way to speed up stuff a bit, is to check if the string is in ASCII (see https://lemire.me/blog/2018/05/16/validating-utf-8-strings-u...) and apply regular operator then.

We implemented many techniques based on "intrinsics" instructions to speed up conversions and search in order to avoid scanning for codepoints.

See https://github.com/naver/tamgu/blob/master/src/conversion.cx... for more information.

Exactly. If you provide a collection, the system will deduce that you want all solutions to be extracted, while if you provide a non collection variable then it will stop once one solution has been found. Actually, I have a very specific type, which is "predicatevar", if you want to get your unification once.

?X is actually a true Prolog variable that can be unified over and over again. Furtheremore, you can call Tamgu functions from your predicate description, in which these variables can be used if they are unified.

grandparent(?X,?Y) :- parent(?X,?Z), println(?Z), parent(?Z,?Y).

In the case above, the "println", which is not a predicate, will try to display the content of ?Z, if ?Z has been unified.

println could be replaced with a call to an actual function, as long as this function returns true. If the function returns false, then it will be considered as a fail.

By the way, you can easily enforce whatever interpretation you want with a cast:

println(vector("i" in s));

Tamgu offers something very similar to that. I borrowed a lot of elements from Haskell, including data management but also declarations. In Tamgu functional elements are enclosed in <..>

In this example, I implement a join that takes a vector and transforms it into a string.

//type declaration

<joining:: vector -> string>

//The function itself

<joining(v) = x | x <- v>

println(joining(['a'..'z']));

Hello,

I provide binaries for Windows, Mac OS, Fedora, Centos and Ubuntu: https://github.com/naver/tamgu/releases

You also have some examples in: https://github.com/naver/tamgu/tree/master/examples

I provide makefiles for all platforms:

Windows: Visual 2013

Mac OS: both command line Makefile and Xcode Makefiles (including the native Mac OS GUI)

Linux: (also for Mac OS), I provide a python script: install.py that determines what is available on your machine and create a Makefile.in.

Actually, there is a simple program: hanoi.tmg in https://github.com/naver/tamgu/tree/master/examples/Predicat..., which shows how to mix Prolog and imperative programming for a benefit of both.

Thank you. Actually, we used this programming language and its ancestors (this is the fifth iteration since 2010) in many evaluation campaigns and it proved very useful. For instance, XML is often the way dataset are exposed and I have encapsulated libxml2 in order to read these files properly. I also provide a kind of BNF grammar compiler to read complex formats and split them into meaningful components. The conversion is really done at the very end of the process, which prevents most errors. Furthermore, Tamgu requires each variable to be explicitly typed in function declarations and for global and local variables, which prevents many of the problems that I used to have with Python. The fact that types are explicit transform many Python runtime errors into compile errors in Tamgu.

Thank you for your comments. Actually, it is possible in Tamgu to have an explicit cast:

i = int(s)+10;

Each type can be used as a "function" to create the object you like, which is basically what a cast is...

None taken... :-)

Well, I did my fair share of programming over the years in so many different languages (Pascal, Cobol, C, C++, Java, Python, APL, Lisp, Prolog, Basic, Small Talk, various assemblers) that I honestly cannot remember all of them.

Tamgu is the result of this experience and my choice was always towards compactness and readability, with Perl being my personal nemesis.

The advantage of this approach is that you don't need to remember a long list of operators, they are simply re-interpreted in context and the re-interpretation is pretty consistent over most of the code.

But, well as the adage goes: Of tastes and colors...

Hello,

I guess I should have been more explicit. I'm sorry for the confusion.

First, Tamgu is a language in which the recipient variable defines the context in which the instruction is evaluated.

If your recipient variable is an integer then everything on the right side of your assignment will be treated as an integer. If it is a string, well everything will be treated as a string.

We use this approach in many other instances:

int pos;

vector v;

string s="This is a testing case";

pos = "i" in s; //we are looking for "i" in the string

In this case, pos==2.

v = "i" in s; //we are looking for all positions of "i" in the string

v == [2,5,14]

Absolutely, you're right. In fact, I first slightly modified the Prolog syntax by replacing the traditional variables that start with a capital letter with variables of the form:"?X". We can therefore differentiate between Tamgu variables and Prolog variables. In addition, Tamgu's basic objects, such as vectors, strings or numbers are automatically reinterpreted as vectors, strings or Prolog numbers.

We can therefore apply operations like: [?X|?Z].

Finally, Tamgu considers that the reception variables before the "=" sign define the execution context. Therefore, if we take the following program:

parent ("John", "Peter").

parent ("John", "Mary").

parent ("Peter", "Roland").

parent ("Roland", "Pierre").

bool b = parent("John",?X);

vector v = parent(?X,?Y);

The first case will return "true" if we find a matching occurrence. Here "b==true".

The second case will return all the possibilities that match:

[parent("John", "Peter"),parent("John", "Mary"),parent("Peter", "Roland"),parent("Roland", "Pierre")

Access to each parameter is possible:

v[0] = parent ("John", "Peter")

v[0][1] == "Peter"

v[0].name() == "parent"

I have been working for years in the NLP and one of my main difficulties during all these years (I will not give any figures, some may think that I belong to a species that has long since disappeared: -) ) was the preparation of the corpora. The corpora are big dirty vicious beasts full of mistakes and traps. The first problem I encountered was the mixing of encodings where a piece of UTF8 mixes with some LATIN leftovers. Tamgu provides quite sophisticated means to solve this problem. The second problem was the parsing of the files to extract the relevant information. That's when I made the decision to offer automatic conversion elements. On the other hand, it should be noted that Tamgu is a typed language and that the interpretation of an object is done in context. When I write:

string s = 10; s += 20;

What I define is an operation within a string. The context is defined by the recipient variable. In the same way:

int i = 20; i += "30";

The variable "i" defines an integer context and therefore string 30 is considered in this case as a number.