Concept about head and tail formalism: [H|T]

Discuss the future of the AutoHotkey language
concepter
Posts: 47
Joined: 24 Aug 2017, 13:02

Concept about head and tail formalism: [H|T]

12 Oct 2017, 10:17

I propose to introduce a very powerful formalism, and used in other programming languages, such as prolog and erlang: dividing a list into head H and tail T with | separator.

Code: Select all

[H|T]
Since in AHK there are no lists but objects and arrays, what I propose is to use formalism on arrays.

Code example in erlang Language where the formalism [H|T] divide the Head from the Tail of the list inside recursive append function.

Code: Select all

append([H|T], Tail) ->
    [H|append(T, Tail)];
append([], Tail) ->
    Tail.
The great force of this formalism fits perfectly with the functional nature of AHK and would increase the expressive capabilities of v2.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Concept about head and tail formalism: [H|T]

12 Oct 2017, 11:52

??
Recommends AHK Studio
concepter
Posts: 47
Joined: 24 Aug 2017, 13:02

Re: Concept about head and tail formalism: [H|T]

13 Oct 2017, 03:30

Most prolog code will not define a list explicitly, like these examples, but rather handle lists of any length, with many possible elements.
To handle lists without knowing what's inside them or how long they are, you use the bar notation:

Code: Select all

[Head|Tail]
In this notation the variable Head represents the leftmost element of the list and the variable Tail represents the rest of the list represented as another list.
A head can be anything, from a predicate to another list, but the tail is always another list.
To find out more about the topic you can go to this page:
https://en.wikibooks.org/wiki/Prolog/Lists
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Concept about head and tail formalism: [H|T]

13 Oct 2017, 04:49

I don't think this is in any way useful especially since you can cause the same effect with very simple AHK code.

Code: Select all

getHead( list )
{
	return list.1 ;I mean like really? why do you need a function for that?
}

getTail( list )
{
	list := list.clone()
	list.removeAt( 1 )
	return list
}
Recommends AHK Studio
concepter
Posts: 47
Joined: 24 Aug 2017, 13:02

Re: Concept about head and tail formalism: [H|T]

15 Oct 2017, 03:30

Of course you can always create a function to perform the task of dividing the head from the tail in a list, but the deep meaning of formalism [H|T] is another.
[H|T] is a formalism that allows you to assign a list item to a variable without using the functions, it is as if it were a mask that captures the elements through their position.
Let me explain better with examples.

If we have a list of Objects = [A, B, C, D, E(e1), F]
we can filter the contents of the list with the following formalisms [H|T] and assign the respective variables:
[Head|Tail] → Head = A, Tail = [B, C, D, E(e1), F]
[Head, Head2|Tail] → Head = A, Head2 = B, Tail = [C, D, E(e1), F]
[Head, Head2, Head3, Head4|Tail] → Head = A, Head2 = B, Head3 = C, Head4 = D, Tail = [E(e1), F]
[Head, Head2, Head3, Head4, Head5, Head6|Tail] → Head = A, Head2 = B, Head3 = C, Head4 = D, Head5 = E(e1), Head6 = F, Tail = []

Being [H|T] a formalism, it helps to write a more compact and readable code, using a native way to divide the elements of a list.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Concept about head and tail formalism: [H|T]

15 Oct 2017, 06:37

I don't think it is very readeable powerful or particulary useful, in fact I only think it is adding additional confusion
Recommends AHK Studio
concepter
Posts: 47
Joined: 24 Aug 2017, 13:02

Re: Concept about head and tail formalism: [H|T]

15 Oct 2017, 08:32

I try to prove that the AHK code could be more clear and legible by introducing formalism [H|T] .
I try to rewrite the two function that you have proposed before, using the formalism inside AHK:

Code: Select all

getHead([H|T]){
	return H
}

getTail([H|T]){
	return T
}
Everything is simpler and clearer, but there may be other possibilities without using the functions, but using only the new-fashioned style:

Code: Select all

[H|T] := [a, b, c, d]   ; new-fashioned style
are equivalent to using the old-fashioned style:

Code: Select all

H := getHead([a,b,c,d])   ; old-fashioned style
T := getTail([a,b,c,d])   ; old-fashioned style
the new-fashioned style:

Code: Select all

[H1,H2|T] := [a, b, c, d]   ; new-fashioned style
are equivalent to using the old-fashioned style:

Code: Select all

H1 := [a,b,c,d].1   ; old-fashioned style
H2 := [a,b,c,d].2   ; old-fashioned style
T := ??? it would serve to define another function to assign T := [c,d] !    ; old-fashioned style
Everything is more readable and clear using the [H|T] formalism, the code is compact and comprehensible.
concepter
Posts: 47
Joined: 24 Aug 2017, 13:02

Re: Concept about head and tail formalism: [H|T]

15 Oct 2017, 08:43

Test comparisons are also possible in the new-fashion style:

Code: Select all

list := [a,b,c,d]
equal := ([a|[b,c,d] = [a,b,c,d])   ; new-fashion style
equal := ([a|[b,c,d] = list)         ; new-fashion style
concepter
Posts: 47
Joined: 24 Aug 2017, 13:02

Re: Concept about head and tail formalism: [H|T]

15 Oct 2017, 08:51

I correct syntactic errors and add some possibilities:

Code: Select all

list := [a,b,c,d]
tail := [b,c,d]

Equal := ([a|[b,c,d]] = [a,b,c,d])   ; new-fashion style
Equal := ([a|tail] = list)             ; new-fashion style
; where Equal are TRUE

Equal := ([a,b|tail] = list)           ; new-fashion style
; where Equal are FALSE

if([a|tail] = list)
   msgbox,, the list are equal !
User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: Concept about head and tail formalism: [H|T]

15 Oct 2017, 11:14

nnnik wrote:I don't think it is very readeable powerful or particulary useful, in fact I only think it is adding additional confusion
+1
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter
Lucas
Posts: 9
Joined: 24 Oct 2013, 08:05

Re: Concept about head and tail formalism: [H|T]

15 Oct 2017, 16:49

I'm a Prolog fan myself and would rather prefer to see a bidirectional API between AHK and Prolog. I've created a new discussion thread for that purpose: https://autohotkey.com/boards/viewtopic ... 37&t=38384
concepter
Posts: 47
Joined: 24 Aug 2017, 13:02

Re: Concept about head and tail formalism: [H|T]

16 Oct 2017, 02:44

Of course it would be nice to have bidirectional APIs between AHK and Prolog, but there are several Prolog implementations, and this could complicate things, but again, it would be nice.
That is why I instead ask to evolve AHK in the direction of Prolog, implementing a basic structure like formalism [H|T].
Since we are talking about possible improvements in AHK v2, introducing new processing methods beyond procedural ones, it would be interesting, and the Prolog and Erlang languages could be inspirational.
Introducing formalism [H|T] would be a first step, relatively simple to integrate: I would very much like AHK to become also a logical and descriptive programming language, completely autonomous, without having to connect to other environments.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Concept about head and tail formalism: [H|T]

16 Oct 2017, 03:21

Yeah but AHKs focus is far from prolog. Changing AutoHotkeys focus is not part of v2s goals as far as I'm aware. I think problems like these will have to wait for v3.
Additionally I see problems with including a single Syntax since they are often meant to be in a set and work on a set. In AutoHotkey something like this would only feel artificial.
We would have to find our own version of that Syntax.
Recommends AHK Studio
concepter
Posts: 47
Joined: 24 Aug 2017, 13:02

Re: Concept about head and tail formalism: [H|T]

16 Oct 2017, 03:38

You are right nnnik about this, and I completely agree, in fact, my want to be a stimulus to the discussion, to bring new programming concepts into AHK.

I just think that formalism [H|T] is universal and easy to implement even in AHK.

That's why I opened another discussion to talk about minikanren, a language for relational programming, originally written in Scheme, which they ported in so many languages, not yet in AHK.

You do not have to wait for a hypothetical version v3, because to implement minikanren, only 40 code lines in Scheme language are needed, corresponding to not knowing how many lines of code in AHK.

Try to look at us and if it is a feasible thing: AHK could become an experimental laboratory for developing the paradigm of relational programming!

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 29 guests